From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-33-i5.italiaonline.it ([212.48.25.234]:52235 "EHLO libero.it" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752657AbcG2ROI (ORCPT ); Fri, 29 Jul 2016 13:14:08 -0400 Reply-To: kreijack@inwind.it Subject: Re: [PATCH 2/5] New btrfs command: "btrfs inspect physical-find" References: <1469641398-3879-1-git-send-email-kreijack@libero.it> <1469641398-3879-3-git-send-email-kreijack@libero.it> <8b013280-7128-d6e4-2f62-b43851d6f6cd@cn.fujitsu.com> <2d33450d-3805-da54-a5e8-2fefde075957@libero.it> <46c7bfc1-8e7a-3a0e-db56-889cf7a324d3@inwind.it> <5cc22a84-e8eb-3ef4-14a9-857430334069@gmx.com> To: Qu Wenruo , Qu Wenruo , linux-btrfs@vger.kernel.org Cc: dsterba@suse.cz, Chris Mason From: Goffredo Baroncelli Message-ID: Date: Fri, 29 Jul 2016 19:14:03 +0200 MIME-Version: 1.0 In-Reply-To: <5cc22a84-e8eb-3ef4-14a9-857430334069@gmx.com> Content-Type: text/plain; charset=utf-8 Sender: linux-btrfs-owner@vger.kernel.org List-ID: On 2016-07-29 08:44, Qu Wenruo wrote: > > > On 07/29/2016 01:08 PM, Goffredo Baroncelli wrote: >> 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....) > > Since it's quite easy for user to assume such find tool will dump > info for the range [offset, offset + 4K(or whatever)). In that > unaligned case, user could get confused about if the tool will dump > the 4K range, including the next stripe. I am still confused: we are talking about three tools: 1) btrfs insp physical-find it is definitely not page boundary dependent 2) btrfs insp physical-dump this implementation is page boundary dependent; and its man-page clear reported this limit; this constraint might be removed with further development. 3) a new tool which dumps the physical location of the file contents. It may be an extension of 1) or a new development, but at this stage it is too early to talk about this limit. am I missing something ? > > Just like map-logical. > > So, if you only mean to dump the stripe info which contains the > bytenr, then makes the doc more clear about the behavior. > > Thanks, Qu > > >> >>> >>> 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 Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5