From owner-freebsd-geom@FreeBSD.ORG  Tue Apr 14 13:25:49 2009
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 008AD106566B;
	Tue, 14 Apr 2009 13:25:49 +0000 (UTC) (envelope-from avg@icyb.net.ua)
Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140])
	by mx1.freebsd.org (Postfix) with ESMTP id 0E56C8FC19;
	Tue, 14 Apr 2009 13:25:47 +0000 (UTC) (envelope-from avg@icyb.net.ua)
Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua
	[212.40.38.101])
	by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA13669;
	Tue, 14 Apr 2009 16:25:34 +0300 (EEST)
	(envelope-from avg@icyb.net.ua)
Message-ID: <49E48ECE.8050809@icyb.net.ua>
Date: Tue, 14 Apr 2009 16:25:34 +0300
From: Andriy Gapon <avg@icyb.net.ua>
User-Agent: Thunderbird 2.0.0.21 (X11/20090406)
MIME-Version: 1.0
To: Ivan Voras <ivoras@freebsd.org>
References: <49E46F44.30606@icyb.net.ua> <gs1tu5$eut$1@ger.gmane.org>
In-Reply-To: <gs1tu5$eut$1@ger.gmane.org>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: freebsd-geom@freebsd.org
Subject: Re: glabel: newfs vs tunefs
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: GEOM-specific discussions and implementations
	<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
	<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
	<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2009 13:25:49 -0000

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