From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Mason Subject: Re: BTRFS partition usage... Date: Tue, 12 Feb 2008 09:35:20 -0500 Message-ID: <200802120935.20437.chris.mason@oracle.com> References: <200802061200.14690.chris.mason@oracle.com> <200802120908.59602.chris.mason@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: linux-fsdevel@vger.kernel.org, btrfs-devel@oss.oracle.com, David Miller , linux-kernel@vger.kernel.org To: Jan Engelhardt Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: btrfs-devel-bounces@oss.oracle.com Errors-To: btrfs-devel-bounces@oss.oracle.com List-Id: linux-fsdevel.vger.kernel.org On Tuesday 12 February 2008, Jan Engelhardt wrote: > On Feb 12 2008 09:08, Chris Mason wrote: > >> >So, if Btrfs starts zeroing at 1k, will that be acceptable for you? > >> > >> Something looks wrong here. Why would btrfs need to zero at all? > >> Superblock at 0, and done. Just like xfs. > >> (Yes, I had xfs on sparc before, so it's not like you NEED the > >> whitespace at the start of a partition.) > > > >I've had requests to move the super down to 64k to make room for > > bootloaders, which may not matter for sparc, but I don't really plan on > > different locations for different arches. > > In x86, there is even more space for a bootloader (some 28k or so) > even if your partition table is as closely packed as possible, > from 0 to 7e00 IIRC. > > For sparc you could have something like > > startlba endlba type > sda1 0 2 1 Boot > sda2 2 58 3 Whole disk > sda3 58 90000 83 Linux > > and slap the bootloader into "MBR", just like on x86. > Or I am missing something.. It was a request from hpa, and he clearly had something in mind. He kindly= =20 offered to review the disk format for bootloaders and other lower level=20 issues but I asked him to wait until I firm it up a bit. =46rom my point of view, 0 is a bad idea because it is very likely to confl= ict=20 with other things. There are lots of things in the FS that need deep=20 thought,and the perfect system to fully use the first 64k of a 1TB filesyst= em=20 isn't quite at the top of my list right now ;) Regardless of offset, it is a good idea to mop up previous filesystems wher= e=20 possible, and a very good idea to align things on some sector boundary. Ev= en=20 going 1MB in wouldn't be a horrible idea to align with erasure blocks on SS= D. =2Dchris