Re: [PATCH] fstests: btrfs: Test send on heavily deduped file

At 07/19/2016 12:35 PM, Eryu Guan wrote: On Tue, Jul 19, 2016 at 10:44:02AM +0800, Qu Wenruo wrote: For fully deduped file, whose file extents are all pointing to the same extent, btrfs backref walk can be very time consuming, long enough to trigger softlock. Unfortunately, btrfs send is one

Re: [PATCH] fstests: btrfs: Test send on heavily deduped file

Add Filipe to the reception, as "To:" doesn't add him automatically. Thanks, Qu At 07/19/2016 10:44 AM, Qu Wenruo wrote: For fully deduped file, whose file extents are all pointing to the same extent, btrfs backref walk can be very time consuming, long enough to trigger softlock.

Re: [PATCH] fstests: btrfs: Test send on heavily deduped file

On Tue, Jul 19, 2016 at 10:44:02AM +0800, Qu Wenruo wrote: > For fully deduped file, whose file extents are all pointing to the same > extent, btrfs backref walk can be very time consuming, long enough to > trigger softlock. > > Unfortunately, btrfs send is one of the caller of such backref walk

[PATCH] fstests: btrfs: Test send on heavily deduped file

For fully deduped file, whose file extents are all pointing to the same extent, btrfs backref walk can be very time consuming, long enough to trigger softlock. Unfortunately, btrfs send is one of the caller of such backref walk under an O(n) loop, making the total time complexity to O(n^3) or

Re: [PATCH] vfs: allow FILE_EXTENT_SAME (dedupe_file_range) on a file opened ro

On Mon, Jul 18, 2016 at 12:13:38AM +0200, Adam Borowski wrote: > Instead of checking the mode of the file descriptor, let's check whether it > could have been opened rw. This allows fixing intermittent exec failures > when deduping a live system: anyone trying to exec a file currently being >

Re: mount btrfs takes 30 minutes, btrfs check runs out of memory

At 07/18/2016 09:42 PM, Josef Bacik wrote: On 07/16/2016 07:53 PM, Qu Wenruo wrote: On 07/15/2016 07:29 PM, Christian Rohmann wrote: Hey Qu, all On 07/15/2016 05:56 AM, Qu Wenruo wrote: The good news is, we have patch to slightly speedup the mount, by avoiding reading out unrelated tree

Re: [PATCH 0/3] Btrfs: fix free space tree bitmaps+tests on big-endian systems

On Mon, Jul 18, 2016 at 02:43:26PM -0400, Chris Mason wrote: > > > On 07/17/2016 08:19 AM, Chandan Rajendra wrote: > > On Friday, July 15, 2016 12:15:15 PM Omar Sandoval wrote: > > > On Fri, Jul 15, 2016 at 12:34:10PM +0530, Chandan Rajendra wrote: > > > > On Thursday, July 14, 2016 07:47:04 PM

Re: Status of SMR with BTRFS

Sorry for late reply, there was a lot of traffic in this thread so: 1. I do apologize but I've got a wrong end of the stick, I was convinced that btrfs does cause corruption on your disk because some of the link that you've hav in original post were pointing to topics with corruptions going on,

Re: [PATCH next] Btrfs: fix comparison in __btrfs_map_block()

On 07/15/2016 09:03 AM, Vincent Stehlé wrote: Add missing comparison to op in expression, which was forgotten when doing the REQ_OP transition. Thanks, added to the 4.8 branch. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to

Re: [PATCH] vfs: allow FILE_EXTENT_SAME (dedupe_file_range) on a file opened ro

On Mon, Jul 18, 2016 at 12:13:38AM +0200, Adam Borowski wrote: > Instead of checking the mode of the file descriptor, let's check whether it > could have been opened rw. This allows fixing intermittent exec failures > when deduping a live system: anyone trying to exec a file currently being >

Re: Status of SMR with BTRFS

On 2016-07-18 15:05, Hendrik Friedel wrote: Hello Austin, thanks for your reply. Ok, thanks; So, TGMR does not say whether or not the Device is SMR or not, right? I'm not 100% certain about that. Technically, the only non-firmware difference is in the read head and the tracking. If it were

Re: Status of SMR with BTRFS

Hello Austin, thanks for your reply. Ok, thanks; So, TGMR does not say whether or not the Device is SMR or not, right? I'm not 100% certain about that. Technically, the only non-firmware difference is in the read head and the tracking. If it were me, I'd be listing SMR instead of TGMR on

Re: Status of SMR with BTRFS

18.7.2016, 0.44, Matthias Prager kirjoitti: the Seagate SMR drives are fast enough to handle Gbit-LAN speeds if they are served mostly large sequential chunks by the file system, which f2fs actually manages to do (cold storage in my scenario too). Btrfs does too many scattered writes for this

Re: [BUG] Btrfs scrub sometime recalculate wrong parity in raid5

Hi On 2016-07-16 17:51, Jarkko Lavinen wrote: > On 07/12/2016 05:50 PM, Goffredo Baroncelli wrote: >> Using "btrfs insp phy" I developed a script to trigger the bug. > > Thank you for the script and all for sharing the raid5 and scrubbing > issues. I have been using two raid5 arrays and ran

Re: Status of SMR with BTRFS

On 2016-07-18 14:31, Hendrik Friedel wrote: Hello and thanks for your replies, It's a Seagate Expansion Desktop 5TB (USB3). It is probably a ST5000DM000. this is TGMR not SMR disk: TGMR is a derivative of giant magneto-resistance, and is what's been used in hard disk drives for decades now.

Re: [PATCH 0/3] Btrfs: fix free space tree bitmaps+tests on big-endian systems

On 07/17/2016 08:19 AM, Chandan Rajendra wrote: On Friday, July 15, 2016 12:15:15 PM Omar Sandoval wrote: On Fri, Jul 15, 2016 at 12:34:10PM +0530, Chandan Rajendra wrote: On Thursday, July 14, 2016 07:47:04 PM Chris Mason wrote: On 07/14/2016 07:31 PM, Omar Sandoval wrote: From: Omar

Re: Status of SMR with BTRFS

Hello and thanks for your replies, It's a Seagate Expansion Desktop 5TB (USB3). It is probably a ST5000DM000. this is TGMR not SMR disk: TGMR is a derivative of giant magneto-resistance, and is what's been used in hard disk drives for decades now. With limited exceptions in recent years and

Re: mount btrfs takes 30 minutes, btrfs check runs out of memory

Qu Wenruo posted on Mon, 18 Jul 2016 17:07:47 +0800 as excerpted: >> Since I'm really surprised on the mount time reduce, especially >> considering the fact that for compression case, max extent size is >> limited to 128K, IMHO defrag won't help much. >> >> Is the 128K limit for the

Re: mount btrfs takes 30 minutes, btrfs check runs out of memory

On 07/16/2016 07:53 PM, Qu Wenruo wrote: On 07/15/2016 07:29 PM, Christian Rohmann wrote: Hey Qu, all On 07/15/2016 05:56 AM, Qu Wenruo wrote: The good news is, we have patch to slightly speedup the mount, by avoiding reading out unrelated tree blocks. In our test environment, it takes

Re: Status of SMR with BTRFS

On 2016-07-17 05:08, Hendrik Friedel wrote: Hi Thomasz, @Dave I have added you to the conversation, as I refer to your notes (https://github.com/kdave/drafts/blob/master/btrfs/smr-mode.txt) thanks for your reply! It's a Seagate Expansion Desktop 5TB (USB3). It is probably a ST5000DM000.

Re: mount btrfs takes 30 minutes, btrfs check runs out of memory

At 07/18/2016 04:53 PM, John Ettedgui wrote: On Mon, Jul 18, 2016 at 1:42 AM Qu Wenruo > wrote: > So following that, another partition got its mounting time reduced by > about 70% by running a manual defrag (I kept compression

Re: mount btrfs takes 30 minutes, btrfs check runs out of memory

At 07/18/2016 04:20 PM, John Ettedgui wrote: On Sun, Jul 17, 2016 at 6:14 PM Qu Wenruo > wrote: Well, compression=no only affects any write after the mount option. And balance won't help to convert compressed extent to

xfstests: error: redefinition of 'struct fsxattr'

Hello! I can't compile xfstests on 4.6.3 kernel (headers installed) on debian sid (unstable). mator@windrunner:~/xfstests$ dpkg -l linux-image-4.6.0-1-amd64 linux-libc-dev Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/