public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Dave Chinner <david@fromorbit.com>, Eric Sandeen <sandeen@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH RFC] xfs: set block device logical sector size on xfs_buftarg
Date: Wed, 13 Nov 2013 16:18:32 -0600	[thread overview]
Message-ID: <5283FAB8.3070307@sandeen.net> (raw)
In-Reply-To: <20131113221009.GK6188@dastard>

On 11/13/13, 4:10 PM, Dave Chinner wrote:

...

> Yet all modern bios implementations you find in hardware can boot 4k
> sector devices just fine.

hm can they really?  Most drives have 512 emulation.

> So, what bios does qemu use?
> 
> $ man qemu
> .....
> QEMU uses the PC BIOS from the Bochs project and the Plex86/Bochs
> LGPL VGA BIOS.
> .....
> 
> So what we have here is an *open source bios* that doesn't handle
> drives 4k sector sizes. There's the problem that needs to be fixed....

And if it wants to boot a guest OS that doesn't handle 4k sectors?
 
<snip>

>> it's our checks in XFS that fail.
> 
> No they don't - they are working just fine. We've told XFS that the
> sector size is X, and therefore we don't allow IO in smaller units,
> data or metadata.  That's the whole point of the filesystem having a
> configurable sector size - we can *enforce* a larger minimum IO
> requirement than the underlying hardware supports.

Semantics.  Yes, they work just fine, by failing the call.

> We've done this for years - e.g. long time ago MD devices had a
> massive performance penalty for sub-page sized IOs, so mkfs set the
> sector size to 4k to avoid that problem, even though we could have
> done 512 byte IOs to the underlying devices.
> 
> Lets fix the problem at the source - the bios that doesn't support
> 4k sector devices - like we've done for all the other utilities that
> need to be aware of disk sector sizes....

I don't disagree with that, but by looking at a 4k/512 drive and deciding
to make 4k sectors, we now present guests with something that barely
exists in the real world: a hard 4k drive w/ no 512 logical fallback.

Hacking up sector sizes in fs/xfs is probably the wrong way to go,
but I'm not sure that essentially forcing hard 4k sectors on every
qemu guest hosted on xfs is a great path either.

Sure, the bios should support 4k - I can ask about that.  But I think
the concern above still stands: in effect we present a device which is
less flexible than the real hardware beneath it; we've removed a
compatibility layer that plenty of software still depends on.

I'm not sure that's the best idea; at best it's unexpected.

-Eric

> Cheers,
> 
> Dave.
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-11-13 22:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-13 18:25 [PATCH RFC] xfs: set block device logical sector size on xfs_buftarg Eric Sandeen
2013-11-13 18:56 ` Christoph Hellwig
2013-11-13 19:08   ` Eric Sandeen
2013-11-13 21:26     ` Dave Chinner
2013-11-13 21:32       ` Eric Sandeen
2013-11-13 22:10         ` Dave Chinner
2013-11-13 22:18           ` Eric Sandeen [this message]
2013-11-14  0:34             ` Dave Chinner
2013-11-14 13:37       ` Christoph Hellwig
2013-11-14 14:56         ` Eric Sandeen
2013-11-14 21:01           ` Dave Chinner
2013-11-22 14:13             ` Ric Wheeler
2013-11-22 14:20               ` Christoph Hellwig
2013-11-22 14:26                 ` Ric Wheeler
2013-11-22 14:57               ` Eric Sandeen
2013-11-14  0:35 ` Eric Sandeen
2013-11-14  6:49   ` Dave Chinner
2013-11-14 13:09     ` Ric Wheeler
2013-11-14 15:03       ` Eric Sandeen
2013-11-14 15:18     ` Eric Sandeen

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=5283FAB8.3070307@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=sandeen@redhat.com \
    --cc=xfs@oss.sgi.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