Re: [PATCH 3/3] btrfs-progs: build: use m4_flatten instead of m4_chomp

On 4/29/18 6:13 AM, David Sterba wrote: > On Fri, Apr 27, 2018 at 03:18:17PM -0400, Jeff Mahoney wrote: >> On 4/27/18 2:56 PM, je...@suse.com wrote: >>> From: Jeff Mahoney >>> >>> Commit 2e1932e6a38 (btrfs-progs: build: simplify version tracking) >>> started m4_chomp to strip the

Re: [PATCH 3/3] btrfs-progs: print-tree: Enhance btrfs_print_tree() check to avoid out-of-boundary memory access

On 2018年04月30日 11:49, Su Yue wrote: > > > On 04/30/2018 11:15 AM, Qu Wenruo wrote: >> For btrfs_print_tree(), if nr_items is corrupted, it can easily go >> beyond extent buffer boundary. >> >> Add extra nr_item check, and only print as many valid slots as possible. >> > > Make sense. > >>

Re: [PATCH 3/3] btrfs-progs: print-tree: Enhance btrfs_print_tree() check to avoid out-of-boundary memory access

On 04/30/2018 11:15 AM, Qu Wenruo wrote: For btrfs_print_tree(), if nr_items is corrupted, it can easily go beyond extent buffer boundary. Add extra nr_item check, and only print as many valid slots as possible. Make sense. Signed-off-by: Qu Wenruo --- print-tree.c | 11

Re: Inconsistent behavior of fsync in btrfs

> On Fri, Apr 27, 2018 at 3:53 PM, Theodore Y. Ts'o wrote: >> On Fri, Apr 27, 2018 at 11:33:29AM -0600, Chris Mason wrote: >>> My goal for the fsync tree log was to make it just do the right thing most >>> of the time. We mostly got there, thanks to a ton of fixes and test cases

Re: Inconsistent behavior of fsync in btrfs

On Sun, Apr 29, 2018 at 5:16 PM, Theodore Y. Ts'o wrote: > On Sun, Apr 29, 2018 at 03:55:39PM -0500, Vijay Chidambaram wrote: >> In the spirit of clarifying fsync behavior, we have one more case >> where we'd like to find out what should be expected. >> >> Consider this: >> >>

Re: BTRFS RAID filesystem unmountable

On 2018年04月29日 22:08, Michael Wade wrote: > Hi Qu, > > Got this error message: > > ./btrfs inspect dump-tree -b 20800943685632 /dev/md127 > btrfs-progs v4.16.1 > bytenr mismatch, want=20800943685632, have=3118598835113619663 > ERROR: cannot read chunk root > ERROR: unable to open /dev/md127 >

Re: BTRFS RAID filesystem unmountable

On 2018年04月29日 22:08, Michael Wade wrote: > Hi Qu, > > Got this error message: > > ./btrfs inspect dump-tree -b 20800943685632 /dev/md127 > btrfs-progs v4.16.1 > bytenr mismatch, want=20800943685632, have=3118598835113619663 > ERROR: cannot read chunk root > ERROR: unable to open /dev/md127 >

Re: [PATCH 2/3] btrfs-progs: Allow tree to be printed without an fs_info

On 04/30/2018 11:15 AM, Qu Wenruo wrote: For btrfs_print_tree() and btrfs_print_leaf(), the usage of fs_info is mainly for nodesize and sectorsize. However for nodesize, we can get it from @eb->len without the need for fs_info at all. For nodesize, introduce new helper

Help

Dear Sir/Madam, I am Sgt Swanson Dennis, I have a good business proposal for you. There are no risks involved and it is easy. Please reply for briefs and procedures. Best regards, Sgt Swanson Dennis -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a

Re: Inconsistent behavior of fsync in btrfs

On Sun, Apr 29, 2018 at 03:55:39PM -0500, Vijay Chidambaram wrote: > In the spirit of clarifying fsync behavior, we have one more case > where we'd like to find out what should be expected. > > Consider this: > > Mkdir A > Creat A/bar > Fsync A/bar > Rename A to B > Fsync B/bar > -- Crash -- >

[PATCH 3/3] btrfs-progs: print-tree: Enhance btrfs_print_tree() check to avoid out-of-boundary memory access

For btrfs_print_tree(), if nr_items is corrupted, it can easily go beyond extent buffer boundary. Add extra nr_item check, and only print as many valid slots as possible. Signed-off-by: Qu Wenruo --- print-tree.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-)

[PATCH 2/3] btrfs-progs: Allow tree to be printed without an fs_info

For btrfs_print_tree() and btrfs_print_leaf(), the usage of fs_info is mainly for nodesize and sectorsize. However for nodesize, we can get it from @eb->len without the need for fs_info at all. For nodesize, introduce new helper BTRFS_NODEPTR_PER_EXTENT_BUFFER() to get nodesize from @eb

[PATCH 1/3] btrfs-progs: Remove fs_info parameter from btrfs_leaf_free_space()

For btrfs_leaf_free_space(), to get leaf data size, we have two way to get it: 1) leaf->fs_info->nodesize 2) leaf->len Anyway, we could get rid of @fs_info parameter for btrfs_leaf_free_space(). And here we choose method 2), as it provides extra benefit to get leaf free space without

Re: [PATCH 1/3] btrfs-progs: Remove fs_info parameter from btrfs_leaf_free_space()

On 04/30/2018 11:15 AM, Qu Wenruo wrote: For btrfs_leaf_free_space(), to get leaf data size, we have two way to get it: 1) leaf->fs_info->nodesize 2) leaf->len Anyway, we could get rid of @fs_info parameter for btrfs_leaf_free_space(). And here we choose method 2), as it provides extra

Re: What is recommended level of btrfs-progs and kernel please

David C. Partridge posted on Sat, 28 Apr 2018 15:09:07 +0100 as excerpted: > To what level of btrfs-progs do you recommend I should upgrade once my > corrupt FS is fixed? What is the kernel pre-req for that? > > Would prefer not to build from source ... currently running Ubuntu > 16.04LTS The

Re: Problems with btrfs

On 2018年04月29日 17:55, David C. Partridge wrote: > Yes I did use seek= > > I attach the new dump-tree - it seems very short compared to the last one you > requested ??? Well, my fault, wrong spell. # btrfs inspect dump-tree -t extent Which should give a lengthy dump. Thanks, Qu > > Dave

[PATCH] btrfs: Take trans lock before access running trans in check_delayed_ref

In preivous patch: Btrfs: kill trans in run_delalloc_nocow and btrfs_cross_ref_exist We avoid starting btrfs transaction and get this information from fs_info->running_transaction directly. When accessing running_transaction in check_delayed_ref, there's a chance that current transaction will be

RE: Problems with btrfs

Here is the result of btrfs check after applying the patch Dave -Original Message- From: Qu Wenruo [mailto:quwenruo.bt...@gmx.com] Sent: 29 April 2018 09:36 To: David C. Partridge Subject: Re: Problems with btrfs Here is the patched binary tree block. You could apply them by the

RE: Problems with btrfs

Yes I did use seek= I attach the new dump-tree - it seems very short compared to the last one you requested ??? Dave -Original Message- From: Qu Wenruo [mailto:quwenruo.bt...@gmx.com] Sent: 29 April 2018 10:36 To: David C. Partridge; linux-btrfs@vger.kernel.org Subject: Re: Problems

Re: [PATCH 3/3] btrfs-progs: build: use m4_flatten instead of m4_chomp

On Fri, Apr 27, 2018 at 03:18:17PM -0400, Jeff Mahoney wrote: > On 4/27/18 2:56 PM, je...@suse.com wrote: > > From: Jeff Mahoney > > > > Commit 2e1932e6a38 (btrfs-progs: build: simplify version tracking) > > started m4_chomp to strip the newlines from the version file. m4_chomp

Re: BTRFS RAID filesystem unmountable

On 2018年04月29日 16:11, Michael Wade wrote: > Thanks Qu, > > Please find attached the log file for the chunk recover command. Strangely, btrfs chunk recovery found no extra chunk beyond current system chunk range. Which means, it's chunk tree corrupted. Please dump the chunk tree with latest

Re: NVMe SSD + compression - benchmarking

Brendan Hide posted on Sat, 28 Apr 2018 09:30:30 +0200 as excerpted: > My real worry is that I'm currently reading at 2.79GB/s (see result > above and below) without compression when my hardware *should* limit it > to 2.0GB/s. This tells me either `sync` is not working or my benchmark > method is

Re: BTRFS RAID filesystem unmountable

On 2018年04月29日 16:59, Michael Wade wrote: > Ok, will it be possible for me to install the new version of the tools > on my current kernel without overriding the existing install? Hesitant > to update kernel/btrfs as it might break the ReadyNAS interface / > future firmware upgrades. > > Perhaps

Re: BTRFS RAID filesystem unmountable

Ok, will it be possible for me to install the new version of the tools on my current kernel without overriding the existing install? Hesitant to update kernel/btrfs as it might break the ReadyNAS interface / future firmware upgrades. Perhaps I could grab this:

Re: Problems with btrfs

On 2018年04月29日 17:20, David C. Partridge wrote: > Here is the result of btrfs check after applying the patch Doesn't work as expected. Did you apply the patched tree block with "seek="? If so, please dump extent tree again to verify if the modification is done correct. # btrfs inspect

Re: Problems with btrfs

On 2018年04月29日 17:59, David C. Partridge wrote: > Here's the correct output - I mistyped inspect so I got the help output > instead of the dump-tree!!! > > David The archive is corrupted. Would you mind to upload it google drive/dropbox? Thanks, Qu > > -Original Message- > From: