From: Dave Chinner <david@fromorbit.com>
To: Carlos Maiolino <cmaiolino@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] libxfs: Get Physical Sector Size instead of Logical Sector size
Date: Sun, 27 Nov 2011 12:06:43 +1100 [thread overview]
Message-ID: <20111127010643.GU2386@dastard> (raw)
In-Reply-To: <20111124195042.GA3671@andromeda.usersys.redhat.com>
On Thu, Nov 24, 2011 at 05:50:42PM -0200, Carlos Maiolino wrote:
> On Thu, Nov 24, 2011 at 05:20:51PM -0200, Carlos Maiolino wrote:
> > xfsprogs (mainly mkfs) is using the logical sector size of a volume to initialize
> > the filesystem, which, even in devices using Advanced Format, it can get a 512
> > bytes sector size if it is set as the logical sector size.
> > This patch changes the ioctl to get the physical sector size, independent of the
> > logical size.
> >
>
> Just as information, this patch proposal does not change the behaviour of mkfs in case the
> user is using libblkid, which in case, mkfs will take advantage of libblkid to retrieve disk
> topology and information.
> I'm not sure if libblkid is the best way to retrieve the device sector's size here, since
> this does not provide a way to retrive the physical sector size, only the logical size, but
> I can be very wrong.
If libblkid exports the PBS (physical block size) as exposed in
/sys/block/<dev>/queue/physical_block_size, then we should be able
to get it.
However, the issue in my mind is not whether it is supported, but
what is the effect of making this change? The filesystem relies on
the fact that the minimum guaranteed unit of atomic IO is a sector,
not the PBS of the underlying disk. What guarantees do we have when
do a PBS sized IO is doesn't get torn into sector sized IOs by the
drive and hence only partitially completed on failure? Indeed, if
the filesystem is sector unaligned, it is -guaranteed- to have PBS
sized IOs torn apart by the hardware....
i.e. do we have any guarantee at all that a PBS sized IO will either
wholly complete or wholly fail when PBS != sector size? And if not,
why is this a change we should make given it appears to me to
violate a fundamental assumption of the filesystem design?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-11-27 1:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-24 19:20 [PATCH] libxfs: Get Physical Sector Size instead of Logical Sector size Carlos Maiolino
2011-11-24 19:50 ` Carlos Maiolino
2011-11-27 1:06 ` Dave Chinner [this message]
2011-11-27 23:05 ` Eric Sandeen
2011-11-27 23:50 ` Dave Chinner
2011-11-28 7:56 ` Christoph Hellwig
2011-11-28 16:08 ` Martin K. Petersen
2011-11-28 16:11 ` Eric Sandeen
2011-11-29 17:15 ` Martin K. Petersen
2011-11-29 17:38 ` Eric Sandeen
2011-11-30 0:19 ` Dave Chinner
2011-11-30 15:03 ` Carlos Maiolino
2011-11-28 16:56 ` Greg Freemyer
2011-11-28 7:54 ` Christoph Hellwig
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=20111127010643.GU2386@dastard \
--to=david@fromorbit.com \
--cc=cmaiolino@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