From owner-freebsd-doc@FreeBSD.ORG Wed Nov 19 18:32:07 2008 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 513471065670 for ; Wed, 19 Nov 2008 18:32:07 +0000 (UTC) (envelope-from fbsdlists@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id F034C8FC17 for ; Wed, 19 Nov 2008 18:32:06 +0000 (UTC) (envelope-from fbsdlists@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so51321yxb.13 for ; Wed, 19 Nov 2008 10:32:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Q3LS99hbdPPc5Sty9n5+nYhHVbFtjYI8tOlCpOy2aSM=; b=hj5XxEpnomJRz+SdDiFHo4DPLr6QNriB18S5zLS0s+08GbLNLh0nefwZmQy1QOtpWg sBoGooVHaCL+t6bXdYV+9D+XVLt8+8Kxy7ZPtaCKQeZDXazPt7q2fMqRwvPIlYsSjC0G SmYFeJuQgsYq3HL8Eryq2Opl/BMgVvkXJLAOE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=DQPQlxw6/Ke4rKWv7VW0u2mt6ZU6guW+ZWU7i8Bq5yBz/36B1Lv8isBrfIaqOVRbbG QJB0y9UjS226cS20qDeNKpthd+yqxSii9ag+xFQfEuqzznQrIkO06MV5ZBNHEy9T3nam LTdc2s2Cs6l9A6X9jM4KSo5tJvis7QFCAgDh8= Received: by 10.90.26.9 with SMTP id 9mr968360agz.59.1227119525928; Wed, 19 Nov 2008 10:32:05 -0800 (PST) Received: by 10.90.114.13 with HTTP; Wed, 19 Nov 2008 10:32:05 -0800 (PST) Message-ID: <54db43990811191032qb4462d6y10104e63c8671298@mail.gmail.com> Date: Wed, 19 Nov 2008 13:32:05 -0500 From: "Bob Johnson" To: "Tom Rhodes" In-Reply-To: <20081112220431.3e451c3e.trhodes@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811120800.mAC80Cm2038380@freefall.freebsd.org> <54db43990811120654l213596f1j844c3f185c3eb577@mail.gmail.com> <20081112200454.3ddb9b89.trhodes@FreeBSD.org> <20081112220431.3e451c3e.trhodes@FreeBSD.org> Cc: freebsd-doc@freebsd.org Subject: Re: docs/128804: Gmirror handbook instructions convert boot-drive to gmirror, truncating last sector X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 18:32:07 -0000 On 11/12/08, Tom Rhodes wrote: > On Wed, 12 Nov 2008 20:04:54 -0500 > Tom Rhodes wrote: > >> On Wed, 12 Nov 2008 09:54:49 -0500 >> "Bob Johnson" wrote: >> >> > The user has no control over whether the last sector of the drive is >> > used for data. Data is scattered all over the drive, in something that >> > resembles a random fashion, and I know of no reason the last sector is >> > not just as likely to have data stored to it as any other sector on >> > the drive (but I am certainly not an authority on the filesystem >> > algorithms). >> > >> > I think a warning is very much in order (that there is a small chance >> > that data will be lost by this procedure). >> > >> > - Bob >> Well, I got distracted and never replied to this, but since the PR is still open, here's more: >> >> Don't Unix file systems attempt to lump data closer together >> in order to reduce this fragmentation which scatters data >> across the entire drive, making it unlikely to have data in >> that last sector unless one went beyond the 8% boundry? In general, no, it is pretty much the opposite. It would be more accurate to view it as intentionally fragmenting the drive in a controlled way so that the problems caused by fragmentation are minimized. The heuristic used probably tends to favor leaving the last sector of the filesystem empty longer than most other sectors, but it can still be used long before the entire filesystem is full (assuming there isn't some other consideration I don't know about -- I'm no expert on the details of the algorithms used). This is because, in general, the goal of the filesystem layout scheme is to avoid completely filling any physical region (cylinder group) if it can be avoided, so it spreads data out among the cylinder groups. This strategy helps keep large chunks of empty space available, so that new data has a good chance of being stored on contiguous sectors. The blocks that belong to one file will tend to be physically close to each other so that the file can be read quickly, but the files themselves end up scattered all over the disk. There are a few ways in which a file can end up being stored on a specific cylinder group, but the result is that the group at the physical end of the filesystem is likely to be used long before the entire filesystem is full. If it happens that the files stored on the last cylinder group are large, or there are many of them, it is possible to write the last sector long before the entire filesystem is full. There is some degree of random chance in the process. -- Bob Johnson fbsdlists@gmail.com