From: Eric Sandeen <sandeen@sandeen.net>
To: Ric Wheeler <rwheeler@redhat.com>, Dave Chinner <david@fromorbit.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Eric Sandeen <sandeen@redhat.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH RFC] xfs: set block device logical sector size on xfs_buftarg
Date: Fri, 22 Nov 2013 08:57:06 -0600 [thread overview]
Message-ID: <528F70C2.6090404@sandeen.net> (raw)
In-Reply-To: <528F66A4.7060200@redhat.com>
On 11/22/13, 8:13 AM, Ric Wheeler wrote:
<snip>
> I think you do that by using SCSI debug to get a 4K sector drive -
> that is how we tested for RHEL6 for example. Layering on restrictions
> to hardware in the file system seems a bit harsh.
>
> The QEMU crowd will be working to get better support for 4K drives in
> the future, but I think that we are effectively going to cause a huge
> field issue here since these 512/4K drives are extremely common..
>
> Given the SCSI debug method for this, does that mean you retract your
> objections and will support Eric's patch :) ?
FWIW, my patch is a disaster, but I'll work on something along those
lines that's not a disaster, so we can discuss it properly. ;)
To make this go, I think we need to add a structure member to the
xfs_buftarg which describes the logical sector size, and use that
to enforce minimum IO sizes. The current sector size fields can
remain in place for the mkfs-specified, presumably physical sector
size.
Then, since the sector sizes in the sb, mp, and buftarg have been
disassociated a bit, I'll need to audit things like the sub-block
zeroing paths so that we DTRT on a sub-block DIO.
At that point, the "sector size" semantics in the mkfs.xfs manpage
get a little weird; if we specify a sector size of 4k, how can
we do sub-sector IOs?
What the mkfs option really means at that point is that the specified
size is the minimum size and alignment which will be generated from
within the filesystem for metadata; we can make it clear that the
underlying logical sector size is still the constraint for userspace
DIO.
I'm not quite sure what the XFS_IOC_DIOINFO ioctl should advertise,
at that point.
Anyway, that's about where I'm at in my brain with all this, will
try to get something that actually works relatively soon.
-Eric
> Regards,
>
> Ric
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-11-22 14:57 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
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 [this message]
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=528F70C2.6090404@sandeen.net \
--to=sandeen@sandeen.net \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=rwheeler@redhat.com \
--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