From owner-freebsd-fs@FreeBSD.ORG Wed Apr 22 13:36:35 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA57F106564A; Wed, 22 Apr 2009 13:36:35 +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 AC47B8FC16; Wed, 22 Apr 2009 13:36:34 +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 QAA17407; Wed, 22 Apr 2009 16:36:32 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <49EF1D5F.7050907@icyb.net.ua> Date: Wed, 22 Apr 2009 16:36:31 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Ivan Voras References: <49EDCA21.70908@icyb.net.ua> <49EDF80F.3070105@icyb.net.ua> <49EF1645.70704@icyb.net.ua> <9bbcef730904220608y73cbf2d2s6921b05c1978a121@mail.gmail.com> <49EF1766.7030401@icyb.net.ua> <9bbcef730904220612s3ff4308fpc1d18e216a5c7773@mail.gmail.com> In-Reply-To: <9bbcef730904220612s3ff4308fpc1d18e216a5c7773@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org Subject: Re: glabel for ufs: size check is overzealous? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 13:36:36 -0000 on 22/04/2009 16:12 Ivan Voras said the following: > 2009/4/22 Andriy Gapon : >> on 22/04/2009 16:08 Ivan Voras said the following: >>> 2009/4/22 Andriy Gapon : >>>> on 21/04/2009 21:43 Ivan Voras said the following: >>>>> Andriy Gapon wrote: >>>>>> I don't see why it should and - no, it actually does not. >>>>>> fsck checks only filesystem's internal consistency, it doesn't check media size, etc. >>>>> Well yes, if the number of blocks is really incorrect it should be >>>>> visible from the arrangement of the metadata but still - that makes the >>>>> field almost useless doesn't it? >>>> How do you mean? >>>> The field tells the filesystem size, how it can be useless? >>> If nothing checks it and everything works, I'd say it's usefulness is >>> a bit limited... >> ufs driver doesn't check it, the driver *uses* it, so... :-) > > But as you said, fsck will not fix an invalid value? It won't, because it can not know the correct value and it is probably not able to safely derive it from anything. Filesystem size is supposed to always stay immutable (modulo growfs), so if this type of corruption happens to superblock, then one has quite a big problem and possibly some fun time with disk editor. -- Andriy Gapon