"zpool create" fails on external HDD (USB) with 4K logical block size

[ancwrd1]

Running the following command:
sudo zpool create -f zbackup /dev/disk/by-id/usb-HitachiG_ST_31001204100000003369-0:0

Produces this error message:
filesystem 'zbackup' can not be mounted due to error 5
cannot mount 'zbackup': Invalid argument

In the kernel log:
sd 17:0:0:0: [sdh] Bad block number requested

I tried it also with "-o ashift=12" with the same result. Running zfs version 0.6.0.82-0ubuntu1~quantal1.

[ancwrd1]

After downgrading to stable ppa (0.6.0.80-1ubuntu1~quantal1) it works.

[dechamps]

Does your code have a5c20e2? If so, can you try without it? With and without ashift=12, please.

[ancwrd1]

Yes I can confirm that this particular commit introduces the regression. It effectively makes external HDD unusable - for both create or import (they both fail with "bad block number" error). Unfortunately I can't test ashift option anymore as this disk holds the backup already, so this is only "zpool import" test.
I tried it also with a normal 512B usb pen drive and no problems there.

[dechamps]

I think that's because your drive shows up as a true 4K drive to Linux. When I wrote a5c20e2 I thought that unaligned requests would work anyway. It seems I was wrong.

@behlendorf: a5c20e2 is wrong and should be reverted. Ideally it should be modified so that it makes sure that requests are at least aligned to the device sector size as seen by the kernel. This way we can still use the optimization on "fake 512" drives.

@Dremon: can you dump the contents of all files in /sys/block/XXX/queue for your drive? This would help pinpointing the issue with the patch. In addition, what's the value of the ashift property of the pool you currently have on the drive?

[ancwrd1]

ashift is right now set to 12 (pool created with the earlier zfs build).

/sys/block/sdh/queue/* dump:

add_random
1
---
discard_granularity
0
---
discard_max_bytes
0
---
discard_zeroes_data
0
---
hw_sector_size
4096
---
iostats
1
---
logical_block_size
4096
---
max_hw_sectors_kb
120
---
max_integrity_segments
0
---
max_sectors_kb
120
---
max_segments
2048
---
max_segment_size
65536
---
minimum_io_size
4096
---
nomerges
0
---
nr_requests
128
---
optimal_io_size
0
---
physical_block_size
4096
---
read_ahead_kb
128
---
rotational
1
---
rq_affinity
1
---
scheduler
[noop] deadline cfq 
---

[dechamps]

Okay, so I think we should make sure I/O requests are at least aligned to hw_sector_size or logical_block_size. Not sure which one to pick between the two.

[behlendorf]

Indeed, thanks guys for verifying this caused the regression. I've reverted the patch from master and referenced this issue for those interested.

[behlendorf]

Closing issue. This should have been closes as part of 0.6.0-rc12 where the offending patch was reverted.