Date: Tue, 14 Apr 2009 16:25:34 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-geom@freebsd.org Subject: Re: glabel: newfs vs tunefs Message-ID: <49E48ECE.8050809@icyb.net.ua> In-Reply-To: <gs1tu5$eut$1@ger.gmane.org> References: <49E46F44.30606@icyb.net.ua> <gs1tu5$eut$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 14/04/2009 15:01 Ivan Voras said the following:
> Andriy Gapon wrote:
>> I am not 100% sure, but it seems that glabel detects newfs -L labels very well,
>> but doesn't see labels set by tunefs -L. I am not sure if ths happens always or
>> "sometimes".
>> Also, I used tunefs without -A option (it's documented as "potentially
>> dangerous"). So could it possibly be that tunefs updates one copy of superblock,
>> but glabel checks some other?
>
> Glabel checks superblocks in the order defined in ufs/ffs/fs.h :
>
> 68 #define SBLOCK_FLOPPY 0
> 69 #define SBLOCK_UFS1 8192
> 70 #define SBLOCK_UFS2 65536
> 71 #define SBLOCK_PIGGY 262144
> 72 #define SBLOCKSIZE 8192
> 73 #define SBLOCKSEARCH \
> 74 { SBLOCK_UFS2, SBLOCK_UFS1, SBLOCK_FLOPPY, SBLOCK_PIGGY, -1 }
>
> So it's theoretically possible that tunefs modifies the old (UFS1)
> location...
OK, superblock location turned out to be a big red herring.
There is a different problem in my case.
>From dumpsfs output:
size 13107199
fsize 2048
>From gpart list output:
Mediasize: 26843545600
26843545600 / 2048 = 13107200 != 13107199
So the filesystem is slightly smaller that it could have been (probably because of
the history of trying gjournal for it).
Thus the following check in g_label_ufs.c fails:
pp->mediasize / fs->fs_fsize == fs->fs_size
While typically a filesystem covers whole available space (in a partition, etc),
it doesn't have to be the case (e.g. newfs has -s option).
So maybe this check is a little bit too strict?
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49E48ECE.8050809>