similar to: [RFC PATCH] Streamline split extent insertions

The memory allocation failure is BUG_ON in add_excluded_extent (following the code path). No need to BUG_ON -ENOMEM inside btrfs_alloc_logged_file_extent. Signed-off-by: Wang Sheng-Hui <shhuiw@gmail.com> --- fs/btrfs/extent-tree.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 95492cc..9b9a6fa 100644 ---

I noticed a few days ago that btrfs fi defrag -cXXX can not be used to compress files unless they are fragmented. The attached patch passes the compression flag to should_defrag_range, where it disables the adjacent-extent and extent size checks if set. The inline/sparse extent check is not modified - I assumed it would not be useful to compress inline extents. -- Andrew Mahone andrew DOT mahone

This patch makes us cache the extent state we find in find_delalloc_range since we''ll have to lock the extent later on in the function. This will keep us from re-searching for the rang when we try to lock the extent. Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/extent_io.c | 11 ++++++++--- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git

Hello everyone, I've just pushed out a large change to btrfs-unstable adding extent back pointers. These will be a big part of online fsck, and migrating blocks around in storage pools as devices change. This is a disk format change for both the progs and the kernel. It does have a small performance impact, but the gain in features is well worth it. I've documented how the back

Dave Sterba pointed out a sleeping while atomic bug while doing fsync. This is because I''m an idiot and didn''t realize that rwlock''s were spin locks, so we''ve been holding this thing while doing allocations and such which is not good. This patch fixes this by dropping the write lock before we do anything heavy and re-acquire it when it is done. We also need

We currently have this problem where you can truncate pages that have not yet been written for an ordered extent. We do this because the truncate will be coming behind to clean us up anyway so what''s the harm right? Well if truncate fails for whatever reason we leave an orphan item around for the file to be cleaned up later. But if the user goes and truncates up the file and tries to

We use set_bit() to assign ordered extent''s flags, but in the related tracepoint we don''t do the same thing, which makes the trace output not to parse flags correctly. Also, since the flags are bits stuff, we change to use __print_flags with a ''delim'' instead of __print_symbolic. Signed-off-by: Liu Bo <bo.li.liu@oracle.com> ---

Now we set @refs to 2 on creating a new extent buffer, meanwhile we allocate the needed free space, but we don''t give enough free_extent_buffer() to reduce the eb''s references to zero so that the eb can finally be freed, so the problem is we has decrease the referene count of backrefs to zero, which ends up releasing the space occupied by the eb, and this space can be allocated

Dear list members, When I tried to recover my partition from the space cache bug (see http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg24360.html ), I issued the command `mount -o clear_cache -t btrfs /dev/sda7 /aaa/aaa`. After 10 minutes the mount command segfaulted. I cloned the latest btrfs-progs from Josef''s Github account and ran the `btrfsck --repair` twice on the

Hi, I''m getting a Kernel Bug when trying to delete some file in a btrfs while using 3.2.0-rc5. Here''s the kernel log: [ 676.672080] btrfs bad tree block start 0 40044687360 [ 676.672233] btrfs bad tree block start 0 40044687360 [ 676.672323] btrfs bad tree block start 0 40044687360 [ 676.672399] btrfs bad tree block start 0 40044687360 [ 676.672488] btrfs bad tree block

Hi All, I''m trying to repair a broken fs using btrfsck and am hitting a failed assertion. I''d appreciate any suggestions for what to do next. Is there any thing I can do to help fix this bug? Any other information from my FS which would help? If the FS could be salvaged that would be a bonus, but I''m more interested in providing a useful bug report before wiping the

On 11/05/19 2:05 AM, Simon Matter via CentOS wrote: >> Am 10.05.2019 um 11:12 schrieb Nux! <nux at li.nux.ro>: >>> I maintain a desktop oriented repo for CentOS and last I checked a year >>> or so ago, I got over 150k+ unique IPs with yum user agent downloading >>> stuff from it. >>> >>> It's a bit anecdotal as perhaps not all are actual

Hello, a backtrace from a machine running a Btrfs RAID0 array with two disks is attached. I''ve never seen this bug before. Please let me know if you need any further info/experiments. Andrej

Hello, I just began digging through the source last night. I hope nobody minds if I just jump in and start sending some patches. The return of extent_map_init is not checked at module startup. The net effect of this function is checked at inode space allocation time though, so my patch decides to quit early on if the alloc fails. Thanks, Wyatt Banks diff -r 29b8cc7794ac extent_map.c ---

Yesterday, I compiled the new kernel 3.0rc1 from git, but I never successed to go over the point: "Removing old temporary files". Pressing control-c let me boot on, but the pc was the complete time on very high load. It took me minutes, just to reach the tty login - and again minutes after login in, that I had my shell and a prompt to enter something. The load was at that time beyond 10.

Originally from https://github.com/markfasheh/duperemove/blob/master/btrfs-extent-same.c Signed-off-by: Gabriel de Perthuis <g2p.code+btrfs@gmail.com> --- .gitignore | 1 + Makefile | 2 +- btrfs-extent-same.c | 145 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 147 insertions(+), 1 deletion(-) create mode 100644 btrfs-extent-same.c diff

Hi all, Did someone have met this problem before. When doing the tests, I hit the WARN_ON. Is this log make sense or someone had fixed the problem. If needed, I can supply the detail log and the testcase source file. Version: the latest codes at linus git tree. [ 2140.981293] use_block_rsv: 336 callbacks suppressed [ 2140.981295] ------------[ cut here ]------------ [ 2140.981308]

>>>>> Radford Neal <radford at cs.toronto.edu> >>>>> on Fri, 9 Sep 2016 10:29:14 -0400 writes: >> Radford Nea: >> > So it may make more sense to move towards consistency in the >> > permissive direction, rather than the restrictive direction. >> >> > That would mean allowing matrix(1,1,1) <

Hi everyone! I'm digging into ggplot for some while now, I must say it's great! But - as some others have posted before, and hadley knows very well himself - the documentation is lacking some bits... So I have to pose that question directly: I'd like to produce a series of maps with different data on, but exactly the same extent in each plot. Is there a way of switching the

Provide for modification of the limit of compressed extent size utilizing mount-time configuration settings. The size of compressed extents was limited to 128K, which leads to fragmentation of the extents (although the extents themselves may still be located contiguously). This limit is put in place to ease the RAM required when spreading compression across several CPUs, and to make sure the