NTFS on OpenBSD, "Invalid argument"

[Smith]

What I have is a genuinely NTFS formatted 4TB drive. (The drive was formatted in Windows 8, fwiw). It's an external USB drive (Western Digital).

What I would like to do is to mount it and access it from OpenBSD. (Yes, I realize it's only 'read only' and this is not a problem!)

What happens is that I get "invalid argument" when I try to mount it using mount_ntfs. I have tried formatting it a few different ways and still the same result. What am I missing? I am still very much an openbsd beginner/ hobbyist..

hostname [~] # dmesg
[ tail end of dmesg ]
umass0 at uhub0 port 5 configuration 1 interface 0 "Western Digital My Book 1230" rev 2.10/10.50 addr 2
umass0: using SCSI over Bulk-Only
scsibus2 at umass0: 2 targets, initiator 0
sd0 at scsibus2 targ 1 lun 0: <WD, My Book 1230, 1050> SCSI4 0/direct fixed
sd0: 3815415MB, 4096 bytes/sector, 976746240 sectors
ses0 at scsibus2 targ 1 lun 1: <WD, SES Device, 1050> SCSI4 13/enclosure services fixed
ses0: unable to read enclosure configuration
hostname [~] # disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: My Book 1230    
duid: 0000000000000000
flags:
bytes/sector: 4096
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 60799
total sectors: 976746240
boundstart: 0
boundend: 976746240
drivedata: 0 

16 partitions:
#                size           offset  fstype [fsize bsize  cpg]
  c:        976746240                0  unused                   
  i:        976735872               63    NTFS                   
hostname [~] # mount /dev/sd0i /mnt/ntfs
mount_ntfs: /dev/sd0i on /mnt/ntfs: Invalid argument

[jggimi]

Welcome back!

I think you may have two separate issues.

Originally Posted by Smith

What I have is a genuinely NTFS formatted 4TB drive....

When I saw this, I thought, "uh oh". That's because MBR partition tables are limited to 2TB, and disks larger appear in the MBR as 2TB. As mentioned in FAQ 14.8, this is not a problem for OpenBSD, as the OpenBSD disklabel doesn't have this restriction. However, you are using a disk that contains only a foreign filesystem, and then a "virtual" disklabel based on the MBR, which is of course limited to 2TB.

Setting the right partition size: I recommend creating a physical disklabel on the drive, so that OpenBSD can address the actual size of the NTFS partition. e.g.: create a small OpenBSD MBR partition of type A6 on the drive, to house the disklabel. This can be a very small partition, such as 1MB in size. Then use disklabel(8) to correctly map the "real" NTFS partition by starting sector and size into the physical disklabel.

Sector size may be an issue: While it may seem simple to humans to use a larger sector size, since the 1970s fixed block architecture drives have been using 512-byte sectors, and 4096-byte sectors are "brand new". There's a lot of OS and driver code that does not support 4096-byte sector drives. Therefore, I would not be surprised if the built-in NTFS driver in OpenBSD might not support 4096-byte sector devices. You should test this with a small NTFS partition, to determine if this is a problem before resolving the 2TB limitation imposed by MBR partitioning. In the event that the built-in NTFS driver does not support 4096-byte sectors, then you might consider trying the ntfs_3g package, which uses OpenBSD's FUSE implementation. Along with the possibility of supporting 4096-byte sectors, this NTFS driver also supports write access.

[J65nko]

The default is to mount for reading and writing. Try to specify a read-only mount with -r.

BTW Does the directory /mnt/ntfs exist?

# ls -ld /mnt/ntfs

[jggimi]

Originally Posted by J65nko

The default is to mount for reading and writing. Try to specify a read-only mount with -r.

For NTFS, a mount without -r will still be read-only

[jggimi]

4K sectors should work, as long as the volume is not Dynamic, according to responses in this misc@ thread that starts here:

http://marc.info/?l=openbsd-misc&m=137443966831448&w=2

[Smith]

Originally Posted by jggimi

Welcome back!

I think you may have two separate issues.When I saw this, I thought, "uh oh". That's because MBR partition tables are limited to 2TB, and disks larger appear in the MBR as 2TB. As mentioned in FAQ 14.8, this is not a problem for OpenBSD, as the OpenBSD disklabel doesn't have this restriction. However, you are using a disk that contains only a foreign filesystem, and then a "virtual" disklabel based on the MBR, which is of course limited to 2TB.

Setting the right partition size: I recommend creating a physical disklabel on the drive, so that OpenBSD can address the actual size of the NTFS partition. e.g.: create a small OpenBSD MBR partition of type A6 on the drive, to house the disklabel. This can be a very small partition, such as 1MB in size. Then use disklabel(8) to correctly map the "real" NTFS partition by starting sector and size into the physical disklabel.

Hay thank you so much!

OK I tested using an old half terabyte drive i had lying around, 4K sectors formatted by Windows do seem to work. I do not think I was confused enough last time to format some sort of dynamic disk.

Then I will bark up the next tree. First thing I am rather naively wondering is, if I can fit this OpenBSD MBR partition you are suggesting into the 63 sectors before the NTFS partition starts. Well.... perhaps it would be wise to screw around with this on my "old drive I had lying around" first ..

Actually, come to think of it, first I will just carefully read the manual entry for OpenBSD's fdisk.

( and yes, /mnt/ntfs does exist and I was just able to mount the above mentioned test NTFS volume on it OK )

[jggimi]

The disklabel's sector location on a drive (or, if there is an MBR partition, within the MBR partition) is architecture specific, defined in /usr/include/machine/disklabel.h

While I think there should be "room" in the first sectors, the first track is reserved for both the MBR and for additional boot blocks, so you may be better off adding a partition entry for OpenBSD -- I'd recommended a megabyte, or, perhaps you can reserve just the second logical track.

The goal is to avoid overlaying anything important: either a boot block, or the disklabel.

[Smith]

Again thanks for the ideas, I had some time to kill and tried .. something (see below), but it still doesn't work. There is a OpenBSD disklabel and a even a rather small ffs partition. Mount (mount_msdos i guess) works on a FAT32 partition but mount_ntfs does not, on the NTFS one.

I reckon i will bark up the ntfs_3g tree next, if nothing else I'm sure I'm not the only one in the world stumped by this and it could be useful for the solution (or a conclusion of an impossibility thereof) to be googlable.

hostname [~] # dmesg | tail -n 7
umass0 at uhub0 port 5 configuration 1 interface 0 "Western Digital My Book 1230" rev 2.10/10.50 addr 2
umass0: using SCSI over Bulk-Only
scsibus2 at umass0: 2 targets, initiator 0
sd0 at scsibus2 targ 1 lun 0: <WD, My Book 1230, 1050> SCSI4 0/direct fixed
sd0: 3815415MB, 4096 bytes/sector, 976746240 sectors
ses0 at scsibus2 targ 1 lun 1: <WD, SES Device, 1050> SCSI4 13/enclosure services fixed
ses0: unable to read enclosure configuration
hostname [~] # disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: My Book 1230    
duid: 0000000000000000
flags:
bytes/sector: 4096
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 60799
total sectors: 976746240
boundstart: 0
boundend: 976746240
drivedata: 0 

16 partitions:
#                size           offset  fstype [fsize bsize  cpg]
  c:        976746240                0  unused                   
  i:        960351872               63    NTFS                   
  j:         16370235        960365700   MSDOS                   
hostname [~] # fdisk -e sd0
Enter 'help' for information
fdisk: 1> print
Disk: sd0       geometry: 60799/255/63 [976746240 4096-byte Sectors]
Offset: 0       Signature: 0xAA55
            Starting         Ending         LBA Info:
 #: id      C   H   S -      C   H   S [       start:        size ]
-------------------------------------------------------------------------------
 0: 07      0   1   1 -  59779  36  32 [          63:   960351872 ] NTFS        
 1: 0B  59780   0   1 -  60798 254  63 [   960365700:    16370235 ] Win95 FAT-32
 2: 00      0   0   0 -      0   0   0 [           0:           0 ] unused      
 3: 00      0   0   0 -      0   0   0 [           0:           0 ] unused      
fdisk: 1> swap 2 1
fdisk:*1> swap 1 0
fdisk:*1> edit 0

partition id ('0' to disable) [0 - FF]: [0] (? for help) A6
Do you wish to edit in CHS mode? [n] 
Partition offset: [0] 15
Partition size: [0] 48 
fdisk:*1> print
Disk: sd0       geometry: 60799/255/63 [976746240 4096-byte Sectors]
Offset: 0       Signature: 0xAA55
            Starting         Ending         LBA Info:
 #: id      C   H   S -      C   H   S [       start:        size ]
-------------------------------------------------------------------------------
 0: A6      0   0  16 -      0   0  63 [          15:          48 ] OpenBSD     
 1: 07      0   1   1 -  59779  36  32 [          63:   960351872 ] NTFS        
 2: 0B  59780   0   1 -  60798 254  63 [   960365700:    16370235 ] Win95 FAT-32
 3: 00      0   0   0 -      0   0   0 [           0:           0 ] unused 
fdisk:*1> write
Writing MBR at offset 0.
fdisk: 1> exit
hostname [~] # disklabel -E sd0
Label editor (enter '?' for help at any prompt)
> p      
OpenBSD area: 15-63; size: 48; free: 48
#                size           offset  fstype [fsize bsize  cpg]
  c:        976746240                0  unused                   
  i:        960351872               63    NTFS                   
  j:         16370235        960365700   MSDOS                   

> a a 
offset: [15] 
size: [48] 
FS type: [4.2BSD] 
Rounding size to bsize (8 sectors): 41 
> p
OpenBSD area: 15-63; size: 48; free: 7
#                size           offset  fstype [fsize bsize  cpg]
  a:               41               15  4.2BSD   4096 32768    1 
  c:        976746240                0  unused                   
  i:        960351872               63    NTFS                   
  j:         16370235        960365700   MSDOS                   
> 
> w
> q
No label changes.
hostname [~] # newfs -b 4096 /dev/rsd0a
/dev/rsd0a: 0.2MB in 328 sectors of 4096 bytes
1 cylinder groups of 0.16MB, 41 blocks, 32 inodes each
super-block backups (for fsck -b #) at:
 32,
hostname [~] # mount /dev/sd0a /mnt/bsd2
hostname [~] # cd /mnt/bsd2
hostname [/mnt/bsd2] # df -h .
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/sd0a      128K    4.0K    120K     3%    /mnt/bsd2
hostname [/mnt/bsd2] # echo "hi" > test.txt
hostname [/mnt/bsd2] # cat test.txt 
hi
hostname [/mnt/bsd2] # cd
hostname [~] # umount /mnt/bsd2
hostname [~] # disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: My Book 1230    
duid: 9d972eeaa21fbcee
flags:
bytes/sector: 4096
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 60799
total sectors: 976746240
boundstart: 15
boundend: 63
drivedata: 0 

16 partitions:
#                size           offset  fstype [fsize bsize  cpg]
  a:               41               15  4.2BSD   4096  4096    1 
  c:        976746240                0  unused                   
  i:        960351872               63    NTFS                   
  j:         16370235        960365700   MSDOS                   
hostname [~] # mount /dev/sd0i /mnt/ntfs
mount_ntfs: /dev/sd0i on /mnt/ntfs: Invalid argument
hostname [~] # mount /dev/sd0j /mnt/msdos
hostname [~] # ls /mnt/msdos
System Volume Information
hostname [~] # umount /dev/sd0j
hostname [~] #

[jggimi]

I think your creation of an FFS filesystem may have overlaid your NTFS partition:

newfs -b 4096 /dev/rsd0a 
/dev/rsd0a: 0.2MB in 328 sectors of 4096 bytes

[Smith]

Originally Posted by jggimi

I think your creation of an FFS filesystem may have overlaid your NTFS partition:

newfs -b 4096 /dev/rsd0a 
/dev/rsd0a: 0.2MB in 328 sectors of 4096 bytes

You would indeed think, but somehow it was not. I just plugged the drive into a windows machine and the drive just appeared as usual, with any files intact. I also ran a filesystem check on this volume from within windows and it's clean ('Disk check complete'). I am not sure why newfs indicates 328 sectors of 4096 bytes (comes to about 1.28 mb) when df -h says 128kb on the mounted file system (which is a little more consistent with the 48 sectors * 4096 bytes = 192 kb I thought i had allocated)

I had to add the '-b 4096' to even get newfs to make such a puny filesystem. I'm sure it's fairly uncommon that anyone would make a 192 kb filesystem on a drive with 4096 byte sectors..

[jggimi]

Here's a stupid question. What release of OpenBSD are you using? NTFS was not added to the GENERIC kernel until OpenBSD 4.9. Prior to that release, NTFS requires a custom kernel.

---

Edited to add:

And, NTFS is only available for the i386 and amd64 architectures. Here's the commit:

http://marc.info/?l=openbsd-cvs&m=128396194505847&w=2

[Smith]

Originally Posted by jggimi

Here's a stupid question. What release of OpenBSD are you using? NTFS was not added to the GENERIC kernel until OpenBSD 4.9. Prior to that release, NTFS requires a custom kernel. And, NTFS is only available for the i386 and amd64 architectures. Here's the commit:

http://marc.info/?l=openbsd-cvs&m=128396194505847&w=2

It's 'OpenBSD 5.4 (GENERIC.MP) #44: Tue Jul 30 12:13:32 MDT 2013' and arch is OpenBSD.i386. Not a stupid question at all since I'm really a bit of a newbie ..

Re the commit note.. I do understand.. I do realize ntfs support is not exactly a red hot priority

[jggimi]

For many years, NTFS support (via a combination of a kernel driver and the mount_ntfs command) were considered experimental, and only read/only access was supported. The mount command was always present, but the admin had to configure and build a custom, unsupported kernel.

With 4.9, NTFS was added to the i386 and amd64 kernels by default. Because this no longer required a custom kernel, the status of NTFS, still read-only, went from experimental to supported.

The comment in the commit was in regards to the future possibility of revising the driver to permit read/write access. This did not come to pass. However, FUSE support was added (intially and experimentally) to OpenBSD at 5.4, and the ntfs_3g FUSE driver was added to the ports tree.

There have been many significant improvements to FUSE support after 5.4. Along with functional improvements since, FUSE was experimental with 5.4, and it would require both a custom kernel and a custom library build in order to enable its operation.

If you are considering using ntfs_3g, you should upgrade to at least 5.5-release.

[Smith]

Originally Posted by jggimi

If you are considering using ntfs_3g, you should upgrade to at least 5.5-release.

OK.. I am now running 5.5 .. ('OpenBSD 5.5 (GENERIC.MP) #262: Wed Mar 5 10:06:29 MST 2014')

I added the package ntfs_3g-2013.1.13p2 . Unfortunately, still no dice. Well, at least I get a little bit more (googlable) information from the error message (and it does seem that ntfs-3g gets a bit more tender and loving care overall than the stock openbsd ntfs code).

Plus hey, I am running 5.5 instead of 5.4, and if I get it working I suppose I could also potentially try writing to a ntfs volume... well, the quest continues!

'Error reading bootsector', this somehow to me suggests that it's not using my painstakingly added openbsd disklabel..

hostname [~] # disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: My Book 1230    
duid: 9d972eeaa21fbcee
flags:
bytes/sector: 4096
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 60799
total sectors: 976746240
boundstart: 15
boundend: 63
drivedata: 0 

16 partitions:
#                size           offset  fstype [fsize bsize  cpg]
  a:               41               15  4.2BSD   4096  4096    1 
  c:        976746240                0  unused                   
  i:        960351872               63    NTFS                   
  j:         16370235        960365700   MSDOS                   
hostname [~] # ntfs-3g /dev/sd0i /mnt/ntfs
Error reading bootsector: Invalid argument
Failed to mount '/dev/sd0i': Invalid argument
The device '/dev/sd0i' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

[Smith]

'Error reading bootsector', this somehow to me suggests that it's not using my painstakingly added openbsd disklabel..

Now I am quite sure there is something fundamental I am missing. I googled around a bit and used ktrace/kdump on the utility ntfsinfo (which produces a similar error). It turned out the point of failure is a call to pread() to get the boot sector, which is where the 'invalid argument' error is returned from. Now I realize I can't even access the first sector as root using dd either:

hostname [~] # dd if=/dev/sd0c of=test.bin bs=512 count=1
dd: /dev/sd0c: Invalid argument
0+0 records in
0+0 records out
0 bytes transferred in 0.000 secs (0 bytes/sec)
hostname [~] # dd if=/dev/rsd0c of=test.bin bs=512 count=1
dd: /dev/rsd0c: Invalid argument
0+0 records in
0+0 records out
0 bytes transferred in 0.000 secs (0 bytes/sec)

Yet mount_msdos seems to manage to read it, and mount the msdos partition which is on the same disk ..

hostname [~] # mount /dev/sd0j /mnt/msdos
hostname [~] # ls /mnt/msdos
System Volume Information
hostname [~] # umount /dev/sd0j

[jggimi]

Wrong block size with dd. Your sectors are 4096 bytes long, not 512 bytes. My supposition at the top of this thread related to this very thing.

Unfortunately, I don't have any 4096-byte sector devices to replicate your environment. If I have time over the weekend, I may try to do so with a virtual machine.

[Smith]

Originally Posted by jggimi

Wrong block size with dd. Your sectors are 4096 bytes long, not 512 bytes. My supposition at the top of this thread related to this very thing.

Yes, you are indeed on to something here. With block size 4096, dd still fails on sd0c but succeeds on rsd0c. With block size 512 it fails on either. (Perhaps this is not surprising to you, but it is to me, I still thought dd could read partial sectors from anything)

hostname [~] # dd if=/dev/sd0c of=test.bin bs=4096 count=1
dd: /dev/sd0c: Invalid argument
0+0 records in
0+0 records out
0 bytes transferred in 0.000 secs (0 bytes/sec)
hostname [~] # dd if=/dev/rsd0c of=test.bin bs=4096 count=1
1+0 records in
1+0 records out
4096 bytes transferred in 0.000 secs (5340287 bytes/sec)

Here is what ktrace/kdump shows when running ntfsinfo -m /dev/sd0i (with a bunch of calls to sigprocmask and mprotect stripped out):

 11464 ntfsinfo CALL  stat(0xcfbda85d,0xcfbda63c)
 11464 ntfsinfo NAMI  "/dev/sd0i"
 11464 ntfsinfo STRU  struct stat { dev=0, ino=78194, mode=brw-r----- , nlink=1, uid=0, gid=5, rdev=1032, atime=1408662125.402751440, mtime=1408617111.421824164, ctime=1408617111.551825287, size=0, blocks=0, blksize=2048, flags=0x0, gen=0xfd9afab1 }
 11464 ntfsinfo RET   stat 0


 11464 ntfsinfo CALL  stat(0x88ca9100,0xcfbda438)
 11464 ntfsinfo NAMI  "/dev/sd0i"
 11464 ntfsinfo STRU  struct stat { dev=0, ino=78194, mode=brw-r----- , nlink=1, uid=0, gid=5, rdev=1032, atime=1408662125.402751440, mtime=1408617111.421824164, ctime=1408617111.551825287, size=0, blocks=0, blksize=2048, flags=0x0, gen=0xfd9afab1 }
 11464 ntfsinfo RET   stat 0

 11464 ntfsinfo CALL  open(0x88ca9100,0<O_RDONLY>)
 11464 ntfsinfo NAMI  "/dev/sd0i"
 11464 ntfsinfo RET   open 3

 11464 ntfsinfo CALL  fcntl(0x3,F_SETLK,0xcfbda4a4)
 11464 ntfsinfo RET   fcntl 0

 11464 ntfsinfo CALL  pread(0x3,0x7bff0a00,0x200,0)
 11464 ntfsinfo RET   pread -1 errno 22 Invalid argument

 11464 ntfsinfo CALL  write(0x2,0xcfbd9d6c,0x18)
 11464 ntfsinfo GIO   fd 2 wrote 24 bytes
       "Error reading bootsector"
 11464 ntfsinfo RET   write 24/0x18

 11464 ntfsinfo CALL  write(0x2,0xcfbd9d3c,0x13)
 11464 ntfsinfo GIO   fd 2 wrote 19 bytes
       ": Invalid argument
       "
 11464 ntfsinfo RET   write 19/0x13

 11464 ntfsinfo CALL  fcntl(0x3,F_SETLK,0xcfbda478)
 11464 ntfsinfo RET   fcntl 0

 11464 ntfsinfo CALL  close(0x3)
 11464 ntfsinfo RET   close 0

 11464 ntfsinfo CALL  write(0x2,0xcfbd9f5c,0x1b)
 11464 ntfsinfo GIO   fd 2 wrote 27 bytes
       "Failed to mount '/dev/sd0i'"
 11464 ntfsinfo RET   write 27/0x1b

 11464 ntfsinfo CALL  fstat(0x3,0xcfbda0c0)
 11464 ntfsinfo STRU  struct stat { dev=5, ino=104405, mode=-r--r--r-- , nlink=1, uid=0, gid=7, rdev=430224, atime=1408620179.394492833, mtime=1394037816, ctime=1408616967.422019440, size=4080, blocks=8, blksize=16384, flags=0x0, gen=0xe001832e }
 11464 ntfsinfo RET   fstat 0

 11464 ntfsinfo CALL  close(0x3)
 11464 ntfsinfo RET   close 0

 11464 ntfsinfo CALL  write(0x2,0xcfbd9f2c,0x13)
 11464 ntfsinfo GIO   fd 2 wrote 19 bytes
       ": Invalid argument
       "
 11464 ntfsinfo CALL  write(0x2,0xcfbd9f5c,0xb9)
 11464 ntfsinfo GIO   fd 2 wrote 185 bytes
       "The device '/dev/sd0i' doesn't have a valid NTFS.
	Maybe you selected the wrong device? Or the whole disk instead of a
	partition (e.g. /dev/hda, not /dev/hda1)? Or the other way around?
       "
 11464 ntfsinfo RET   write 185/0xb9

 11464 ntfsinfo CALL  write(0x1,0x83c85000,0x1c)
 11464 ntfsinfo GIO   fd 1 wrote 28 bytes
       "Failed to open '/dev/sd0i'.
       "
 11464 ntfsinfo RET   write 28/0x1c

 11464 ntfsinfo CALL  exit(0x1)

The '-m' arguments just means 'read and display the metadata for the ntfs volume'. I checked, ntfsinfo also fails in the same way on rsd0i. If you notice the dump above, it tries to read 0x200 = 512 bytes from file descriptor 3, which is /dev/sd0i :

 11464 ntfsinfo CALL  open(0x88ca9100,0<O_RDONLY>)
 11464 ntfsinfo NAMI  "/dev/sd0i"
 11464 ntfsinfo RET   open 3

 11464 ntfsinfo CALL  pread(0x3,0x7bff0a00,0x200,0)
 11464 ntfsinfo RET   pread -1 errno 22 Invalid argument

Have we really discovered some sort of esoteric 4096-byte sector irregularity in both mount_ntfs and ntfs-3g? Or what am I missing?

(In this case, esoteric, but to become more commonplace perhaps as these large sector sizes take over the planet completely)

[Smith]

... or could it be some weird memory alignment issue, that becomes evident here but not so much under Linux, because perhaps OpenBSD handles RAM itself differently?

Eg in the dump from the failed ntfsinfo execution I notice that 0x7bff0a00 (which I imagine is the address in RAM of the buffer for pread() to store the data) just happens to be divisible by 512, but not by 4096.

[jggimi]

Thanks for doing the digging. I happened upon this comment at Tuxera just now.

With a 4K-sector disk, you must use ntfs-3g version at least 2012.1.15.

The version with 5.5-release is 2013.1.13, so either short-sector reads are OK on other OSes, which is possible, or some sector sizes were still hard-coded in 2013.1.13.

OpenBSD-5.6 will use version 2014.2.15. I haven't looked at the code for either. Again, if I have a few hours I will try to replicate the problem this weekend.

[Smith]

Originally Posted by jggimi

Thanks for doing the digging. I happened upon this comment at Tuxera just now.The version with 5.5-release is 2013.1.13, so either short-sector reads are OK on other OSes, which is possible, or some sector sizes were still hard-coded in 2013.1.13.

OpenBSD-5.6 will use version 2014.2.15. I haven't looked at the code for either. Again, if I have a few hours I will try to replicate the problem this weekend.

OK. Yes indeed, 2013.1.13 is what it seems to be. I still don't understand why also dd fails with a block length shorter than the physical blocks. For example, with even shorter blocks (256 bytes long), dd works on a 512 bytes/sector disk (wd0c) but fails on the 4096 bytes/sector one (sd0c). Same system.. there really is something I am not understanding here.. either there is some mystical interaction between the different software parts between the actual disk and /dev/sd0, [uhub- umass- scsibus- whatnot], or this is the standard defined behavior of dd when you use smaller block size than physical size. (Also on a small linux machine (raspberrypi) dd seems to be OK with 256 bytes long blocks .. )

hostname [~] # dd if=/dev/sd0c of=test.bin bs=256 count=1
dd: /dev/sd0c: Invalid argument
0+0 records in
0+0 records out
0 bytes transferred in 0.000 secs (0 bytes/sec)
hostname [~] # dd if=/dev/wd0c of=test.bin bs=256 count=1
1+0 records in
1+0 records out
256 bytes transferred in 0.000 secs (276757 bytes/sec)
hostname [~] #