linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@sun.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Eric Sandeen <sandeen@redhat.com>,
	ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH, RFC] mke2fs: get device topology values from blkid
Date: Fri, 18 Sep 2009 08:18:11 -0600	[thread overview]
Message-ID: <20090918141811.GT2537@webber.adilger.int> (raw)
In-Reply-To: <yq1k4zw93vu.fsf@sermon.lab.mkp.net>

On Sep 18, 2009  02:13 -0400, Martin K. Petersen wrote:
> >>>>> "Eric" == Eric Sandeen <sandeen@redhat.com> writes:
> Eric> This is just a rough cut, due to the blkid header selection issues
> Eric> I mentioned earlier on the list.  It'll also need some config-fu
> Eric> to be sure we've got a blkid which has these calls, but with it in
> Eric> place, we'll finally have automatic selection of stride/stripe:
> 
> What about alignment?

As yet we don't handle wacky alignment.  For Lustre customers we tell them
not to create partition tables, but it would be nice to handle all of the
strange alignment issues internally.

> I know that in our friendly DM universe the volume will be aligned.  But
> what if the user does mkfs on /dev/sdX and the drive isn't naturally
> aligned?
> 
> How flexible is the extN on-disk format?  Can you pad and shift things
> if need be?

Not in sub-block offsets, which means that partition tables and drive
geometry, etc. should at least align on multiples of the blocksize,
and ideally multiples of the "minimum" IO size.

The mballoc allocator CAN handle non-power-of-two allocations, if the
geometry tells it the minimum/optimum IO size needs it, but as yet it
doesn't have an "offset" parameter.  It just assumes that block 0 is
aligned properly.  I suspect it wouldn't be hard to add this, though
to make it efficient it would require munging the buddy bitmaps.

> Also, are you guys affected by the previously-acked-sectors-are-now-gone
> problems with 512-byte logical/4KB physical drives?

Not that I'm aware of.  The ext4 journal commit block is below 512 bytes,
and virtually all ext4 filesystems are using 4kB blocks.  

Maybe that was XFS?

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.


  reply	other threads:[~2009-09-18 14:18 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-17 22:22 [PATCH, RFC] mke2fs: get device topology values from blkid Eric Sandeen
2009-09-18  5:55 ` Andreas Dilger
2009-09-18 14:04   ` Eric Sandeen
2009-09-18 14:20     ` Andreas Dilger
2009-09-18 14:30       ` Eric Sandeen
2009-09-18 16:43       ` Theodore Tso
2009-09-18 16:57         ` Eric Sandeen
2009-09-18  6:13 ` Martin K. Petersen
2009-09-18 14:18   ` Andreas Dilger [this message]
2009-09-18 14:23   ` Eric Sandeen
2009-09-18 19:40     ` Martin K. Petersen
2009-09-18 20:28       ` Andreas Dilger
2009-09-20 20:46         ` Martin K. Petersen
2009-09-22 14:30           ` Ric Wheeler
2009-09-18 23:59 ` Karel Zak
2009-09-19  3:03   ` Eric Sandeen
2009-09-21 17:06 ` [PATCH V2] " Eric Sandeen
2009-10-02 16:32   ` [PATCH V3] " Eric Sandeen
2009-10-04 19:16     ` Theodore Tso

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=20090918141811.GT2537@webber.adilger.int \
    --to=adilger@sun.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=sandeen@redhat.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).