On Mon, Oct 31, 2016 at 03:04:27PM +0800, Qu Wenruo wrote: > > > At 10/31/2016 02:37 PM, Marc MERLIN wrote: > >On Mon, Oct 31, 2016 at 02:32:53PM +0800, Qu Wenruo wrote: > >> > >> > >>At 10/31/2016 02:25 PM, Marc MERLIN wrote: > >>>On Mon, Oct 31, 2016 at 02:04:10PM +0800, Qu Wenruo wrote: > >>>>>Sorry for asking, am I doing this wrong? > >>>>>myth:~# dd if=/dev/mapper/crypt_bcache0 of=/tmp/dump1 bs=512 count=32 > >>>>>skip=26367830208 > >>>>>dd: reading `/dev/mapper/crypt_bcache0': Invalid argument > >>>>>0+0 records in > >>>>>0+0 records out > >>>>>0 bytes (0 B) copied, 0.000401393 s, 0.0 kB/s > >>>> > >>>>So, the underlying MD RAID5 are complaining about some wrong data, and > >>>>refuse to read out. > >>>> > >>>>It seems that btrfs-progs can't handle read failure? > >>>>Maybe dm-error could emulate it. > >>>> > >>>>And what about the 2nd range? > >>> > >>>they both fail the same, but I wasn' tsure if I typed the wrong dd command > >>>or not. > >> > >>Strange, your command seems OK to me. > >> > >>Does it has anything to do with your security setup or something like that? > >>Or is it related to dm-crypt or bcache? > >> > >> > >>But this reminds me, if dd can't read it, maybe btrfs-progs is the same. > >> > >>Maybe only kernel can read dm-crypt device while user space tools can't > >>access dm-crypt devices directly? > > > >It can, it's just the offset seems wrong: > > > >myth:~# dd if=/dev/mapper/crypt_bcache0 of=/tmp/dump1 bs=512 count=32 > >skip=26367830208 > >dd: reading `/dev/mapper/crypt_bcache0': Invalid argument > >0+0 records in > >0+0 records out > >0 bytes (0 B) copied, 0.000421662 s, 0.0 kB/s > > > >If I divide by 1000, it works: > >myth:~# dd if=/dev/mapper/crypt_bcache0 of=/tmp/dump1 bs=512 count=32 > >skip=26367830 > >32+0 records in > >32+0 records out > >16384 bytes (16 kB) copied, 0.139005 s, 118 kB/s > > > >so that's why I was asking you if I counted the offset wrong. I took the > >value you asked and divided by 512, but it seems too big > > > >13500329066496 / 512 = 26367830208 > > > >Marc > > > But according to your dump-super output, that's strange. > ------ > chunk_root 13835462344704 (CR) > item 0 key (FIRST_CHUNK_TREE CHUNK_ITEM 13835461197824) (CS) > chunk length 33554432 owner 2 stripe_len 65536 > type SYSTEM|DUP num_stripes 2 > stripe 0 devid 1 offset 13500327919616 (ST1) > dev uuid: 0cf779be-8e16-4982-b7d7-f8241deea0d1 > stripe 1 devid 1 offset 13500361474048 (ST2) > dev uuid: 0cf779be-8e16-4982-b7d7-f8241deea0d1 > ------ > > Here, your chunk logical bytenr is 13835461197824, and its physical > bytenr is 13500327919616 and 13500361474048. > > My calculation is quite simple. > Start1 = CR - CS + ST1 > Start2 = CR - CS + ST2 > > Unless the superblock is incorrect, it is not possile. > > And the physical offset, is about 12.2 TiB, which is smaller than > 15TiB of your device. > > So that's quite strange that dd can't read out the data. > And if dd can't read it out, then I see no reason btrfs-progs can > read it out. > > Any idea on special dm setup which can make us fail to read out some > data range?
I've seen both btrfs check and btrfs dump-super give wrong answers (particularly, some addresses end up larger than the device, for some reason) when run on a mounted filesystem. Worth ruling that one out. Hugo. -- Hugo Mills | Great films about cricket: Silly Point Break hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: E2AB1DE4 |
signature.asc
Description: Digital signature
