Displaying 20 results from an estimated 9000 matches similar to: "Btrfs TODO"
2012 Oct 01
1
[RFC] [PATCH] Btrfs: rework can_nocow_odirect
I need everybody to go over this with a fine toothed comb since it is a pretty
big change. I think it is right and it seems to come out right, but if it''s not
it will mean we screw up O_DIRECT on snapshotted files with preallocated
extents, so please, make sure it is correct :).
---
Subject: [PATCH] Btrfs: rework can_nocow_odirect
We are always doing the file extent lookup in here
2013 Aug 22
11
Samba strict allocate = yes stops btrfs compression working
Hi,
If i set strict allocate = yes in samba to speed up the transfer
of a mssql database dump,
then btrfs does not compress the file.
I have tried it also by just copying a small file in Windows to the
samba share and the same.
I have tried btrfs mount options autodefrag and then
btrfs fi defrag -c and the file still does not get compressed.
I have tried kernels 3.6.11, 3.8 and 3.10.7 on FC16
2010 Aug 29
7
Re: BTRFS: Unbelievably slow with kvm/qemu
Christoph Hellwig wrote:
> There are a lot of variables when using qemu.
>
> The most important one are:
>
> - the cache mode on the device. The default is cache=writethrough,
> which is not quite optimal. You generally do want to use cache=none
> which uses O_DIRECT in qemu.
> - if the backing image is sparse or not.
> - if you use barrier - both in the host
2012 Apr 20
44
Ceph on btrfs 3.4rc
After running ceph on XFS for some time, I decided to try btrfs again.
Performance with the current "for-linux-min" branch and big metadata
is much better. The only problem (?) I''m still seeing is a warning
that seems to occur from time to time:
[87703.784552] ------------[ cut here ]------------
[87703.789759] WARNING: at fs/btrfs/inode.c:2103
2013 Jan 03
4
btrfsck: extent-tree.c:2549: btrfs_reserve_extent: Assertion `!(ret)' failed.
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
2012 Aug 15
6
State of nocow file attribute
Hello,
some time ago we discussed on #btrfs that the nocow attribute for files wasn''t
working (around 3.3 or 3.4 kernels). That was evident by files fragmenting even
with the attribute set.
Chris mentioned to find a fix quickly for that, and posted some lines of change
into irc. But recently someone mentioned that 3.6-rc looks like still not
respecting nocow for files.
Is there really
2010 May 07
6
[PATCH 1/5] fs: allow short direct-io reads to be completed via buffered IO V2
V1->V2: Check to see if our current ppos is >= i_size after a short DIO read,
just in case it was actually a short read and we need to just return.
This is similar to what already happens in the write case. If we have a short
read while doing O_DIRECT, instead of just returning, fallthrough and try to
read the rest via buffered IO. BTRFS needs this because if we encounter a
compressed or
2012 Dec 13
22
[PATCH] Btrfs: fix a deadlock on chunk mutex
An user reported that he has hit an annoying deadlock while playing with
ceph based on btrfs.
Current updating device tree requires space from METADATA chunk,
so we -may- need to do a recursive chunk allocation when adding/updating
dev extent, that is where the deadlock comes from.
If we use SYSTEM metadata to update device tree, we can avoid the recursive
stuff.
Reported-by: Jim Schutt
2013 Dec 11
5
Updated btrfs-next
Hello,
I just updated and pushed btrfs-next, if it is missing something let me
know. I had to kick out the printk formatting patch because it didn''t
compile and I didn''t take Miao''s background enospc flushing stuff since
some of it didn''t apply and 5/5 hasn''t been updated to force waiting on
background flushers. Let me know if I missed anything
2010 Mar 12
2
[PATCH] Btrfs: force delalloc flushing when things get desperate
When testing with max_extents=4k, we enospc out really really early. The reason
for this is we really overwhelm the system with our worst case calculation.
When we try to flush delalloc, we don''t want everybody to wait around forever,
so we wake up the waiters when we''ve done some of the work in hopes that its
enough work to get everything they need done. The problem with this
2011 May 11
8
[PATCH 1/4] Btrfs: map the node block when looking for readahead targets
If we have particularly full nodes, we could call btrfs_node_blockptr up to 32
times, which is 32 pairs of kmap/kunmap, which _sucks_. So go ahead and map the
extent buffer while we look for readahead targets. Thanks,
Signed-off-by: Josef Bacik <josef@redhat.com>
---
fs/btrfs/ctree.c | 23 +++++++++++++++++++++--
1 files changed, 21 insertions(+), 2 deletions(-)
diff --git
2012 Sep 17
13
[PATCH 1/2 v3] Btrfs: use flag EXTENT_DEFRAG for snapshot-aware defrag
We''re going to use this flag EXTENT_DEFRAG to indicate which range
belongs to defragment so that we can implement snapshow-aware defrag:
We set the EXTENT_DEFRAG flag when dirtying the extents that need
defragmented, so later on writeback thread can differentiate between
normal writeback and writeback started by defragmentation.
This patch is used for the latter one.
Originally patch
2012 Mar 02
1
nocow flags
I set the C (NOCOW) and z (Not_Compressed) flags on a folder but the extent counts of files contained there keep increasing.
Said files are large and frequently modified but not changing in size. This does not happen when the filesystem is mounted with nodatacow.
I''m using this as a workaround since subvolumes can''t be mounted with different options simultaneously. ie. one with
2008 Nov 13
7
Kernel oops when running bonnie++ on btrfs
I wanted to see how btrfs compares to other filesystems so I have been
running bonnie++ on it. While the results are good(much faster then
ext2) every once in awhile I get a kernel oops. I am testing on xubuntu
8.10 with the 2.6.27-7-686 kernel using the latest git sources. Most of the
time the oops happens within 20min of running bonnie++ but sometimes it
takes a few hours. This happens with and
2013 Nov 15
7
[PATCH 1/2] xfstests: add generic/321 to test fsync() on directories V2
Btrfs had some issues with fsync()''ing directories and fsync()''ing after
renames. These three new tests cover the 3 different issues we were seeing.
This breaks out the dmflakey stuff into a common helper to be shared between
generic/311 and generic/321. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
---
V1->V2: rename test to generic/321
-removed an
2011 Oct 04
3
[PATCH] Btrfs: break out of orphan cleanup if we can't make progress V2
I noticed while running xfstests 83 that if we didn''t have enough space to
delete our inode the orphan cleanup would just loop. This is because it keeps
finding the same orphan item and keeps trying to kill it but can''t because we
don''t get an error back from iput for deleting the inode. So keep track of the
last guy we tried to kill, if it''s the same as the
2013 Jan 21
1
btrfs_start_delalloc_inodes livelocks when creating snapshot under IO
Greetings all,
I see the following issue during snap creation under IO:
Transaction commit calls btrfs_start_delalloc_inodes() that locks the
delalloc_inodes list, fetches the first inode, unlocks the list,
triggers btrfs_alloc_delalloc_work/btrfs_queue_worker for this inode
and then locks the list again. Then it checks the head of the list
again. In my case, this is always exactly the same
2010 May 06
1
[PATCH 1/3] fs: allow short direct-io reads to be completed via buffered IO V2
V1->V2: Check to see if our current ppos is >= i_size after a short DIO read,
just in case it was actually a short read and we need to just return.
This is similar to what already happens in the write case. If we have a short
read while doing O_DIRECT, instead of just returning, fallthrough and try to
read the rest via buffered IO. BTRFS needs this because if we encounter a
compressed or
2013 Aug 30
17
[PATCH] rwsem: add rwsem_is_contended
Btrfs uses an rwsem to control access to its extent tree. Threads will hold a
read lock on this rwsem while they scan the extent tree, and if need_resched()
they will drop the lock and schedule. The transaction commit needs to take a
write lock for this rwsem for a very short period to switch out the commit
roots. If there are a lot of threads doing this caching operation we can starve
out the
2013 Sep 23
12
balance induced csum errors
SAMSUNG SSD 830 Series
CPU0: IntelĀ® Core(TM) i7-2820QM CPU @ 2.30GHz (fam: 06, model: 2a, stepping: 07)
8GB RAM (quite heavily tested, not recently, with several days of memtest)
kernel 3.11.1-200.fc19.x86_64 running on baremetal
btrfs-progs-0.20.rc1.20130308git704a08c-1.fc19.x86_64
Today I did a scrub on a btrfs volume, with no message or errors in console or dmesg or journal. Immediately after