On 2016-07-29 03:34, Qu Wenruo wrote: >> I am not against about your proposal; however I have to point out >> that the goal of these command was not to *traverse* the file, but >> only to found the physical location of a file offset. My use case >> was to simulate a corruption of a raid5 stripe elements: for me it >> was sufficient to know the page position. > > For corruption case, the best practice would be extending > btrfs-corrupt-block command. > > And for your original proposal, to locate a page/sector containing > the bytenr/offset, then the returned value should always be aligned > to sectorsize. (And we need to state it clear in both man page and > help string) > > Unfortunately, that's not the case in current implementation. (And > don't forget future subpage sector size, so in that case, we need to > check sectorsize first.) > > For example, if user passes a unaligned logical, physical-find will > return the device offset unaligned.
For the other command (physical-dump), there is a check about the alignment; the reason was to simplify the dump of the content. However I don't understand to the reason to ask for the alignment even in the -find tool: why the output have to be aligned ? Which is the difference if I return the first byte address of the file than the 2nd or the 3rd (taking in account all the detail, which for raid5/6 is not very easy....) > > If only to locate the stripe/sector, at least returning a aligned > number seems more reasonable. > > IMHO if we only want a simple tool, then make it clear it's a just > simple tool, and add limitation and explain to make it simple and > won't accept any complext/unexpected input. > > Or, make it handle unexpected and complex input well. > > > BTW, long time ago, btrfs-map-logical is under the same situation, > just a simple tool do off-line logical->device offset mapping. But it > since it does provides offset/length pair options, it can cause wrong > or uesless result for unaligned input. And we spent some time to > improve it. > > So I hope we can avoid such problem which has already happened in > map-logical. -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
