xfstests: 091,240,268 fix for xfs on 4k sector hard drive
PATCH 1/1 xfstests: 091,240,268 fix for xfs on 4k sector hard drive
Tests 091,240, and 268 are failing on my 4k sector hard disk. The dio writes from fsx and aiodio_sparse2 are failing on xfs with EINVAL which is returned from the check at the top of xfs_file_dio_aio_write().
The fix is to use blockdev -getpbsz to get the physical sector size instead of the logical sector size. This makes 091 and 268 work. 240 will not run on a 4k drive since fs block size == device block size. Tested against xfs,ext4, and btrfs.
--- tests/generic/091 | 2 +- tests/generic/240 | 2 +- tests/generic/263 | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
tests/generic/091 +1 -1
@@ -54,7 +54,7 @@ run_fsx() } psize=`$here/src/feature -s` -bsize=`blockdev --getss $TEST_DEV` +bsize=`blockdev --getpbsz $TEST_DEV` kernel=`uname -r | sed -e 's/\(2\..\).*/\1/'` # 2.4 Linux kernels support bsize aligned direct I/O only
tests/generic/240 +1 -1
@@ -60,7 +60,7 @@ rm -f $seqres.full rm -f $TEST_DIR/aiodio_sparse -logical_block_size=`blockdev --getss $TEST_DEV` +logical_block_size=`blockdev --getpbsz $TEST_DEV` fs_block_size=`stat -f $TEST_DIR | grep "Block size:" | awk '{print $3}'` if [ $fs_block_size -le $logical_block_size ]; then
tests/generic/263 +1 -1
@@ -54,7 +54,7 @@ run_fsx() } psize=`$here/src/feature -s` -bsize=`blockdev --getss $TEST_DEV` +bsize=`blockdev --getpbsz $TEST_DEV` run_fsx -N 10000 -o 8192 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z run_fsx -N 10000 -o 128000 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z
Signature · 6 lines
1.8.1.4 _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Re: [PATCH] xfstests: 091, 240, 268 fix for xfs on 4k sector hard drive
Quoted 8 lines · Dwight Engen
Tests 091,240, and 268 are failing on my 4k sector hard disk. The dio writes from fsx and
aiodio_sparse2are failing on xfs with EINVAL which is returned from the check at the top ofxfs_file_dio_aio_write().The fix is to use blockdev -getpbsz to get the physical sector size instead of the logical sector size. This makes 091 and 268 work. 240 will not run on a 4k drive since fs block size == device block size. Tested against xfs,ext4, and btrfs.
What's the logical sector size of the drive? If it's 4k, then blockdev --getss should be returning 4k. If it's not, then either the drive is reporting that it supports 512 bytes sectors when it doesn't (i.e. the drive is broken) or blockdev is returning the wrong information (i.e. blockdev is broken)....
What does mkfs.xfs output on that device?
tests/generic/240 rm -f $seqres.full · line 63
Quoted 4 lines
rm -f $TEST_DIR/aiodio_sparse
tests/generic/240 +1
-1-logical_block_size=`blockdev --getss $TEST_DEV` +logical_block_size=`blockdev --getpbsz $TEST_DEV`
FWIW, that doesn't make much sense - putting the physical block size into a variable named "logical_block_size".....
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Re: [PATCH] xfstests: 091, 240, 268 fix for xfs on 4k sector hard drive
Quoted 26 lines · Dave Chinner
Quoted 8 lines · Dwight Engen
Tests 091,240, and 268 are failing on my 4k sector hard disk. The dio writes from fsx and
aiodio_sparse2are failing on xfs with EINVAL which is returned from the check at the top ofxfs_file_dio_aio_write().The fix is to use blockdev -getpbsz to get the physical sector size instead of the logical sector size. This makes 091 and 268 work. 240 will not run on a 4k drive since fs block size == device block size. Tested against xfs,ext4, and btrfs.
What's the logical sector size of the drive? If it's 4k, then blockdev --getss should be returning 4k. If it's not, then either the drive is reporting that it supports 512 bytes sectors when it doesn't (i.e. the drive is broken) or blockdev is returning the wrong information (i.e. blockdev is broken)....
What does mkfs.xfs output on that device?
tests/generic/240 rm -f $seqres.full · line 63
Quoted 4 lines
rm -f $TEST_DIR/aiodio_sparse
tests/generic/240 +1
-1-logical_block_size=`blockdev --getss $TEST_DEV` +logical_block_size=`blockdev --getpbsz $TEST_DEV`FWIW, that doesn't make much sense - putting the physical block size into a variable named "
logical_block_size".....
Quoted 3 lines
Cheers,
Dave.
AFAIK there are no native 4K sector drives on the market yet. All of the currently shipping models with physical 4K sectors are "Advanced Format" drives. The Advanced Format standard specifies 4K physical sectors -internal- to the drive, but with traditional 512B LBA addressing.
Dwight, what disk drive is this in question? Make/model?
Signature · 6 lines
Stan _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Re: [PATCH] xfstests: 091, 240, 268 fix for xfs on 4k sector hard drive
Quoted 12 lines · On Wed, 24 Jul 2013 23:36:38 -0500 Stan Hoeppner <[email protected]> wrote:
Quoted 11 lines · Dave Chinner
Quoted 9 lines · Dwight Engen
Tests 091,240, and 268 are failing on my 4k sector hard disk. The dio writes from fsx and
aiodio_sparse2are failing on xfs with EINVAL which is returned from the check at the top ofxfs_file_dio_aio_write().The fix is to use blockdev -getpbsz to get the physical sector size instead of the logical sector size. This makes 091 and 268 work. 240 will not run on a 4k drive since fs block size == device block size. Tested against xfs,ext4, and btrfs.
Quoted 5 lines
Quoted 5 lines
What's the logical sector size of the drive? If it's 4k, then blockdev --getss should be returning 4k. If it's not, then either the drive is reporting that it supports 512 bytes sectors when it doesn't (i.e. the drive is broken) or blockdev is returning the wrong information (i.e. blockdev is broken)....
# blockdev --getss /dev/sda 512 # blockdev --getpbsz /dev/sda 4096
So it looks like blockdev is reporting the correct values.
Quoted 1 line
Quoted 1 line
What does mkfs.xfs output on that device?
mkfs.xfs -f /dev/sda1
meta-data=/dev/sda1 isize=256 agcount=8, agsize=262144
blks = sectsz=4096 attr=2, projid32bit=0
data = bsize=4096 blocks=2097152, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal log bsize=4096 blocks=2560, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0So mkfs.xfs is reporting sectsz=4096. I added a printf into mkfs.xfs right after it is setting sectorsize = ft.psectorsize and saw:
sectorsize 4096 ft.psectorsize 4096 ft.lsectorsize 512
Quoted 7 lines
Quoted 7 lines
tests/generic/240 rm -f $seqres.full · line 63
Quoted 4 lines
rm -f $TEST_DIR/aiodio_sparse
tests/generic/240 +1
-1-logical_block_size=`blockdev --getss $TEST_DEV` +logical_block_size=`blockdev --getpbsz $TEST_DEV`FWIW, that doesn't make much sense - putting the physical block size into a variable named "
logical_block_size".....
Yeah, that name wouldn't make much sense with this change. Its actually being used to compare to the fs block size and then its passed into aiodio_sparse2 as offset. 091 and 268 use the more generic name bsize, should I can change it to that?
Quoted 11 lines
Quoted 3 lines
Cheers,
Dave.
AFAIK there are no native 4K sector drives on the market yet. All of the currently shipping models with physical 4K sectors are "Advanced Format" drives. The Advanced Format standard specifies 4K physical sectors -internal- to the drive, but with traditional 512B LBA addressing.
Dwight, what disk drive is this in question? Make/model?
Yep its an Advanced Format drive, some relevant lines from dmesg:
ata1.00: ATA-8: HITACHI HTS725050A7E630, GH2ZB390, max UDMA/133
scsi 0:0:0:0: Direct-Access ATA HITACHI HTS72505 GH2Z PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB) sd 0:0:0:0: [sda] 4096-byte physical blocks
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Re: [PATCH] xfstests: 091, 240, 268 fix for xfs on 4k sector hard drive
Quoted 40 lines · Dwight Engen
Quoted 12 lines · On Wed, 24 Jul 2013 23:36:38 -0500 Stan Hoeppner <[email protected]> wrote:
Quoted 11 lines · Dave Chinner
Quoted 9 lines · Dwight Engen
Tests 091,240, and 268 are failing on my 4k sector hard disk. The dio writes from fsx and
aiodio_sparse2are failing on xfs with EINVAL which is returned from the check at the top ofxfs_file_dio_aio_write().The fix is to use blockdev -getpbsz to get the physical sector size instead of the logical sector size. This makes 091 and 268 work. 240 will not run on a 4k drive since fs block size == device block size. Tested against xfs,ext4, and btrfs.
Quoted 5 lines
Quoted 5 lines
What's the logical sector size of the drive? If it's 4k, then blockdev --getss should be returning 4k. If it's not, then either the drive is reporting that it supports 512 bytes sectors when it doesn't (i.e. the drive is broken) or blockdev is returning the wrong information (i.e. blockdev is broken)....
# blockdev --getss /dev/sda 512 # blockdev --getpbsz /dev/sda 4096So it looks like blockdev is reporting the correct values.
Quoted 1 line
Quoted 1 line
What does mkfs.xfs output on that device?
mkfs.xfs -f
/dev/sda1
meta-data=/dev/sda1 isize=256 agcount=8, agsize=262144
blks = sectsz=4096 attr=2, projid32bit=0data = bsize=4096 blocks=2097152, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0
Quoted 4 lines
So mkfs.xfs is reporting sectsz=4096. I added a printf into mkfs.xfs right after it is setting sectorsize = ft.psectorsize and saw:
sectorsize 4096 ft.psectorsize 4096 ft.lsectorsize 512
There was a change to mkfs to make the sectorsize == physical sector size:
commit 287d168b550857ce40e04b5f618d7eb91b87022f
Author: Eric Sandeen <[email protected]> Date: Thu Mar 1 22:46:35 2012 -0600
mkfs.xfs: properly handle physical sector size
This splits the fs_topology structure "sectorsize" into logical & physical, and gets both via blkid_get_topology().
This primarily allows us to default to using the physical sectorsize for mkfs's "sector size" value, the fundamental size of any IOs the filesystem will perform.
and the rationale was:
/*
* Unless specified manually on the command line use the
+ * advertised sector size of the device. We use the physical + * sector size unless the requested block size is smaller + * than that, then we can use logical, but warn about the + * inefficiency.
So, I hadn't thought about this, but I guess using physical sector size during mkfs trickles all the way to the DIO tests, and rejects anything smaller, including otherwise-acceptable smaller logical sector sizes :/
(You can probably mkfs w/ an explicit 512 sector size, and confirm that 512-byte DIOs work again)
bleah, perhaps that was a mistake - or perhaps we need to fix kernelspace to prefer physical-size IOs, but allow logical-size if a DIO requests it.
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
tests/generic/240 rm -f $seqres.full · line 63
Quoted 4 lines
rm -f $TEST_DIR/aiodio_sparse
tests/generic/240 +1
-1-logical_block_size=`blockdev --getss $TEST_DEV` +logical_block_size=`blockdev --getpbsz $TEST_DEV`FWIW, that doesn't make much sense - putting the physical block size into a variable named "
logical_block_size".....
Quoted 4 lines
Yeah, that name wouldn't make much sense with this change. Its actually being used to compare to the fs block size and then its passed into
aiodio_sparse2as offset. 091 and 268 use the more generic name bsize, should I can change it to that?
Well, that was put there with:
commit 2dbd21dc152d89715263990c881025f17c7b632e
Author: Jeff Moyer <[email protected]> Date: Fri Feb 11 15:20:02 2011 -0500
240: only run when the file system block size is larger than the disk sector size
This test really wants to test partial file-system block I/Os. Thus, if the device has a 4K sector size, and the file system has a 4K block size, there's really no point in running the test. In the attached patch, I check that the fs block size is larger than the device's logical block size, which should cover a 4k device block size with a 16k fs block size.
I verified that the patched test does not run on my 4k sector device with a 4k file system. I also verified that it continues to run on a 512 byte logical sector device with a 4k file system block size.
...
+# This test need only be run in the case where the logical block size +# of the device can be smaller than the file system block size.
Quoted 19 lines
Quoted 11 lines
Quoted 3 lines
Cheers,
Dave.
AFAIK there are no native 4K sector drives on the market yet. All of the currently shipping models with physical 4K sectors are "Advanced Format" drives. The Advanced Format standard specifies 4K physical sectors -internal- to the drive, but with traditional 512B LBA addressing.
Dwight, what disk drive is this in question? Make/model?
Yep its an Advanced Format drive, some relevant lines from dmesg:
ata1.00: ATA-8: HITACHI HTS725050A7E630, GH2ZB390, max UDMA/133
scsi 0:0:0:0: Direct-Access ATA HITACHI HTS72505 GH2Z PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB) sd 0:0:0:0: [sda] 4096-byte physical blocks
Quoted 5 lines
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Re: [PATCH] xfstests: 091, 240, 268 fix for xfs on 4k sector hard drive
On Thu, 25 Jul 2013 10:23:19 -0500
Eric Sandeen <[email protected]> wrote:
[...]
Quoted 2 lines
(You can probably mkfs w/ an explicit 512 sector size, and confirm that 512-byte DIOs work again)
Hi Eric, yep, confirmed that doing mkfs.xfs -b size=1024 (used 1024 instead of 512 so that 240 would run) makes 091, 240, and 268 work without my changes.
Quoted 3 lines
bleah, perhaps that was a mistake - or perhaps we need to fix kernelspace to prefer physical-size IOs, but allow logical-size if a DIO requests it.
ext4 and btrfs did work, so perhaps that is what they are doing, I have not looked yet.
[... test 240]
Quoted 26 lines
Quoted 10 lines
Quoted 5 lines
Quoted 5 lines
tests/generic/240 rm -f $seqres.full · line 63
Quoted 2 lines
tests/generic/240 +1
-1-logical_block_size=`blockdev --getss $TEST_DEV` +logical_block_size=`blockdev --getpbsz $TEST_DEV`FWIW, that doesn't make much sense - putting the physical block size into a variable named "
logical_block_size".....Yeah, that name wouldn't make much sense with this change. Its actually being used to compare to the fs block size and then its passed into
aiodio_sparse2as offset. 091 and 268 use the more generic name bsize, should I can change it to that?Well, that was put there with:
commit
2dbd21dc152d89715263990c881025f17c7b632eAuthor: Jeff Moyer <[email protected]> Date: Fri Feb 11 15:20:02 2011 -0500240: only run when the file system block size is larger than the
disk sector size
This test really wants to test partial file-system block I/Os.
Thus, if the device has a 4K sector size, and the file system has a 4K block size, there's really no point in running the test. In the attached patch, I check that the fs block size is larger than the device's logical block size, which should cover a 4k device block size with a 16k fs block size.
Quoted 6 lines
I verified that the patched test does not run on my 4k sector
device with a 4k file system. I also verified that it continues to run on a 512 byte logical sector device with a 4k file system block size.Signed-off-by Jeff Moyer <[email protected]>Signed-off-by Christoph Hellwig <[email protected]>
The name was added in this commit, and the message would lead me to believe that Jeff intended for the test to not run on a 4k physical sector disk with a 4k fs, so is the "logical_block_size" name a misnomer?
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Re: [PATCH] xfstests: 091, 240, 268 fix for xfs on 4k sector hard drive
Quoted 10 lines · Dwight Engen
On Thu, 25 Jul 2013 10:23:19 -0500
Eric Sandeen <[email protected]> wrote:[...]
Quoted 2 lines
(You can probably mkfs w/ an explicit 512 sector size, and confirm that 512-byte DIOs work again)
Hi Eric, yep, confirmed that doing mkfs.xfs -b size=1024 (used 1024 instead of 512 so that 240 would run) makes 091, 240, and 268 work without my changes.
Ok; that's because a specified block size < physical sector size switches the "sector size" setting in the superblock back down to logical sector size.
-b 4096 -s 512 should make it work too.
Quoted 6 lines
Quoted 3 lines
bleah, perhaps that was a mistake - or perhaps we need to fix kernelspace to prefer physical-size IOs, but allow logical-size if a DIO requests it.
ext4 and btrfs did work, so perhaps that is what they are doing, I have not looked yet.
well, they probably don't have this "sector size" notion throughout the code like we do.
Quoted 34 lines
[... test 240]
Quoted 26 lines
Quoted 10 lines
Quoted 5 lines
Quoted 5 lines
tests/generic/240 rm -f $seqres.full · line 63
Quoted 2 lines
tests/generic/240 +1
-1-logical_block_size=`blockdev --getss $TEST_DEV` +logical_block_size=`blockdev --getpbsz $TEST_DEV`FWIW, that doesn't make much sense - putting the physical block size into a variable named "
logical_block_size".....Yeah, that name wouldn't make much sense with this change. Its actually being used to compare to the fs block size and then its passed into
aiodio_sparse2as offset. 091 and 268 use the more generic name bsize, should I can change it to that?Well, that was put there with:
commit
2dbd21dc152d89715263990c881025f17c7b632eAuthor: Jeff Moyer <[email protected]> Date: Fri Feb 11 15:20:02 2011 -0500240: only run when the file system block size is larger than the
disk sector size
This test really wants to test partial file-system block I/Os.
Thus, if the device has a 4K sector size, and the file system has a 4K block size, there's really no point in running the test. In the attached patch, I check that the fs block size is larger than the device's logical block size, which should cover a 4k device block size with a 16k fs block size.Quoted 6 lines
I verified that the patched test does not run on my 4k sector
device with a 4k file system. I also verified that it continues to run on a 512 byte logical sector device with a 4k file system block size.Signed-off-by Jeff Moyer <[email protected]>Signed-off-by Christoph Hellwig <[email protected]>
Quoted 4 lines
The name was added in this commit, and the message would lead me to believe that Jeff intended for the test to not run on a 4k physical sector disk with a 4k fs, so is the "
logical_block_size" name a misnomer?
Well, it wants to be able to do sub-fs-block-sized direct IO.
Jeff assumed that the DIO limitation would be logical block size, but the mkfs commit I referenced changed the limit to physical block size, which I think is a mistake, in retrospect. At least for the buftarg sector sizes, we should probably set it to logical sector size, to allow smaller DIOs if requested. Let me give that some thought.
-Eric
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Re: [PATCH] xfstests: 091, 240, 268 fix for xfs on 4k sector hard drive
In reply to Stan HoeppnerQuoted 4 lines · Stan Hoeppner
AFAIK there are no native 4K sector drives on the market yet. All of the currently shipping models with physical 4K sectors are "Advanced Format" drives. The Advanced Format standard specifies 4K physical sectors -internal- to the drive, but with traditional 512B LBA addressing.
There are some (SAS) drives that do only 4K sectors. Not sure how popular they are,
Ric
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Re: [PATCH] xfstests: 091, 240, 268 fix for xfs on 4k sector hard drive
Quoted 9 lines · Ric Wheeler
Quoted 5 lines · Stan Hoeppner
AFAIK there are no native 4K sector drives on the market yet. All of the currently shipping models with physical 4K sectors are "Advanced Format" drives. The Advanced Format standard specifies 4K physical sectors -internal- to the drive, but with traditional 512B LBA addressing.
There are some (SAS) drives that do only 4K sectors. Not sure how popular they are,
Google returns nothing on native 4KB drives at any drive vendor site, other than two transition documents at Seagate and Toshiba extolling the benefits of 512e technology.
I can't find a press release. If native 4KB drives are indeed available, the vendors sure don't appear too eager to tell the world about them. The drives of which you speak, are these engineering samples, OEM production only (EMC/IBM/etc), or general availability?
Which vendor makes the drives of which you speak?
Signature · 6 lines
Stan _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Re: [PATCH] xfstests: 091, 240, 268 fix for xfs on 4k sector hard drive
Hi Ric,
Can you point me in the general direction of these native 4K sector SAS drives? A vendor at least? Thus far I'm unable to locate them.
Thanks.
Stan
Quoted 15 lines · Stan Hoeppner
Quoted 9 lines · Ric Wheeler
Quoted 5 lines · Stan Hoeppner
AFAIK there are no native 4K sector drives on the market yet. All of the currently shipping models with physical 4K sectors are "Advanced Format" drives. The Advanced Format standard specifies 4K physical sectors -internal- to the drive, but with traditional 512B LBA addressing.
There are some (SAS) drives that do only 4K sectors. Not sure how popular they are,
Google returns nothing on native 4KB drives at any drive vendor site, other than two transition documents at Seagate and Toshiba extolling the benefits of 512e technology.
Quoted 6 lines
I can't find a press release. If native 4KB drives are indeed available, the vendors sure don't appear too eager to tell the world about them. The drives of which you speak, are these engineering samples, OEM production only (EMC/IBM/etc), or general availability?
Which vendor makes the drives of which you speak?
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs