LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: Jan Engelhardt <jengelh@computergmbh.de>
Cc: David Miller <davem@davemloft.net>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	btrfs-devel@oss.oracle.com
Subject: Re: BTRFS partition usage...
Date: Tue, 12 Feb 2008 09:35:20 -0500	[thread overview]
Message-ID: <200802120935.20437.chris.mason@oracle.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0802121518500.21102@fbirervta.pbzchgretzou.qr>

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 
offered to review the disk format for bootloaders and other lower level 
issues but I asked him to wait until I firm it up a bit.

>From my point of view, 0 is a bad idea because it is very likely to conflict 
with other things.  There are lots of things in the FS that need deep 
thought,and the perfect system to fully use the first 64k of a 1TB filesystem 
isn't quite at the top of my list right now ;)

Regardless of offset, it is a good idea to mop up previous filesystems where 
possible, and a very good idea to align things on some sector boundary.  Even 
going 1MB in wouldn't be a horrible idea to align with erasure blocks on SSD.

-chris

  reply	other threads:[~2008-02-12 14:36 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-06 17:00 [ANNOUNCE] Btrfs v0.12 released Chris Mason
2008-02-11  1:12 ` David Miller
2008-02-11 13:42   ` Chris Mason
2008-02-12  6:43     ` David Miller
2008-02-12 13:43       ` Chris Mason
2008-02-12  7:21 ` BTRFS partition usage David Miller
2008-02-12  8:11   ` David Miller
2008-02-12 13:49     ` Chris Mason
2008-02-12 14:00       ` Jan Engelhardt
2008-02-12 14:08         ` Chris Mason
2008-02-12 14:21           ` Jan Engelhardt
2008-02-12 14:35             ` Chris Mason [this message]
2008-02-12 15:04               ` Jan Engelhardt
2008-02-12 16:17                 ` Chris Mason
2008-02-12 23:38                 ` David Miller
2008-02-12 23:42                   ` Jan Engelhardt
2008-02-13  1:09                     ` David Miller
2008-02-13  1:22                     ` Rene Herman
2008-02-12 23:35               ` David Miller
2008-02-13  7:02                 ` Christoph Hellwig
2008-02-12 23:34             ` David Miller
2008-02-12 23:33           ` David Miller
2008-02-13  2:10             ` Jeff Garzik
2008-02-14  0:51               ` Szabolcs Szakacsits
2008-02-12 23:26         ` David Miller
2008-02-12 23:39           ` Jan Engelhardt
2008-02-13  1:08             ` David Miller
2008-02-13  1:25           ` Bryan Henderson
2008-02-12 23:28         ` David Miller
2008-02-13  0:45           ` Theodore Tso
2008-02-12 20:50       ` David Miller
2008-02-12  9:23 ` CRC32C big endian bugs David Miller
2008-02-12 21:55 ` BTRFS only works with PAGE_SIZE <= 4K David Miller
2008-02-12 22:03   ` Chris Mason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200802120935.20437.chris.mason@oracle.com \
    --to=chris.mason@oracle.com \
    --cc=btrfs-devel@oss.oracle.com \
    --cc=davem@davemloft.net \
    --cc=jengelh@computergmbh.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: BTRFS partition usage...' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).