On Wed, Feb 15, 2017 at 07:24:55PM +0100, Goffredo Baroncelli wrote: > The chunk-tree maps the logical address [145096704...145096704+134217728) [size=128MB] to the physical ones > devid3 : [63111168..63111168+67108864) [size=64MB] > devid1 : [63111168..63111168+67108864) [size=64MB] > devid2 : [83034112..83034112+67108864) [size=64MB] > > So because the logical address is divided in pieces of 64k, interleaved by the parity, we know that: > * first 128kb > logical address [145096704 ..145096704+64k) -> devid1, [63111168 ..63111168+64k) > logical address [145096704+64k ..145096704+2x64k) -> devid2, [83034112 ..83034112+64k) > parity: -> devid3, [63111168 ..63111168+64k) > * second 128kb > logical address [145096704+2x64k..145096704+3x64k) -> devid2, [83034112+64k..83034112+2x64k) > logical address [145096704+3x64k..145096704+4x64k) -> devid3, [63111168+64k..63111168+2x64k) > parity: -> devid1, [63111168+64k..63111168+2x64k) > And so on... > > (NB: 145096704+2x64k == 145227776) > > The fs-tree, maps the file content [0..131072) [size=128k] to the logical address [145227776..145227776+131072) [size=128k] > > So the file content is stored starting from the disk devid2, at 83034112+64k=83099648 (first 64k). The second 64k is placed in disk devid3 at 63111168+64k=63176704; the parity is stored at disk1, 63111168+64k = 63176704 > > > BR > G.Baroncelli > Thanks for the detailed example with exact numbers. Now understood the address mapping better. With this as a reference, I think it should be possible to access parity/data-stripes more sensible manner instead using expensive "cat /device/ | hexdump | grep" combination. thanks. Cheers. Lakshmipathi.G -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
