Quote:
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)
Code:
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):
Code:
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 :
Code:
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)