glabel: newfs vs tunefs

[Andriy Gapon]

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