Displaying 20 results from an estimated 10000 matches similar to: "ENOSPC Regression"
2009 Nov 05
7
Unexpected ENOSPC on a SSD-drive after day of uptime, kernel 2.6.32-rc5
I''ve just finished installing onto an OCZ Agilent v2 SSD with btrfs as
filesystem. However to my surprise I''ve hit an ENOSPC condition one
one of the partitions within less than a day of uptime, while the
filesystem on that partition only reported 50% to be in use, which is
far from the 75% limit people mention on the ML.
Note that this occurs using a vanilla 2.6.32-rc5 kernel
2012 Jul 31
2
Btrfs Intermittent ENOSPC Issues
I''ve been working on running down intermittent ENOSPC issues.
I can only seem to replicate ENOSPC errors when running zlib
compression. However, I have been seeing similar ENOSPC errors to a
lesser extent when playing with the LZ4HC patches.
I apologize for not following up on this sooner, but I had drifted
away from using zlib, and didn''t notice there was still an issue.
My
2011 Nov 29
3
[PATCH] fs: push file_update_time into ->page_mkwrite
The fault code has been calling file_update_time after ->page_mkwrite after it
drops the page lock, but this is annoying because this calls mark_inode_dirty
which can fail in Btrfs, so we want to be able to do these updates in
->page_mkwrite so we can get an error back to the user. So get rid of the
file_update_time calls in the fault code and push it into everybody who has a
2012 Apr 08
4
[PATCH] Revert "Btrfs: increase the global block reserve estimates"
This reverts commit 5500cdbe14d7435e04f66ff3cfb8ecd8b8e44ebf.
We had numerous reports of premature ENOSPC that were bisected to this
patch. Reverting will not break things but a warning in ''use_block_rsv''
may show up in the syslog.
There''s no alternative fix in sight and the ENOSPC problem affects all
3.3 btrfs users during normal filesystem use.
CC:
2009 Apr 09
7
Btrfs TODO
Hello,
Trying to put together a list of TODO items for btrfs so we can update the wiki
page fully. So far these things are on the list
* Proper ENOSPC handling
* O_DIRECT support (without checksumming)
* AIO support
* Subvolume quotas and inherited space usage information
* Snapshot removal
* QA Suite for automated regression testing
* Reserved space for online fsck and the ability to add
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
2008 Oct 10
1
[PATCH] fix enospc when there is plenty of space
Hello,
So there is an odd case where we can possibly return -ENOSPC when there is in
fact space to be had. I think I finally have a hold on what the problem is, it
only happens with Metadata writes, and happens _very_ infrequently. What has to
happen is we have to allocate have allocated out of the first logical byte on
the disk, which would set last_alloc to first_logical_byte(root, 0), so
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
2012 May 23
1
[PATCH] Btrfs: fall back to non-inline if we don't have enough space
If cow_file_range_inline fails with ENOSPC we abort the transaction which
isn''t very nice. This really shouldn''t be happening anyways but there''s no
sense in making it a horrible error when we can easily just go allocate
normal data space for this stuff. Thanks,
Signed-off-by: Josef Bacik <josef@redhat.com>
---
fs/btrfs/inode.c | 5 ++++-
1 files changed, 4
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
2011 Sep 10
12
WARNING: at fs/btrfs/inode.c:2193 btrfs_orphan_commit_root+0xb0/0xc0 [btrfs]()
Hi
I am hitting this Warning reproducible, the workload is a ceph osd,
kernel ist 3.1.0-rc5.
Best Regards,
martin
[ 5472.099766] ------------[ cut here ]------------
[ 5472.099833] WARNING: at fs/btrfs/inode.c:2193
btrfs_orphan_commit_root+0xb0/0xc0 [btrfs]()
[ 5472.099838] Hardware name: MS-96B3
[ 5472.099842] Modules linked in: radeon ttm drm_kms_helper drm
i2c_algo_bit psmouse sp5100_tco
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
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
2013 Feb 11
2
[PATCH] btrfs: accept zero for balance usage filter
The condition can be relaxed to accept also 0 which will delete
unoccupied chunks and does not need space for the actual data
relocation. Until there is an automatic empty chunk reclaim, we
can use this as a last resort option under enospc.
CC: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
---
Also needs progs update, but is not required for the
2010 Dec 29
1
Reproducible kernel BUG while using VirtualBox:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All,
I believe that I can pretty reliably reproduce the BUG mentioned in the
attached dmesg output. (This doesn''t mean that you can, but I''ll detail
what I''ve done here.) [This BUG is the same one that I reported last night.]
1) Create a 2 GB dynamically expanding disk.
2) Attach it to a VirtualBox machine.
3) Start the
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
2011 Nov 09
12
WARNING: at fs/btrfs/inode.c:2198 btrfs_orphan_commit_root+0xa8/0xc0
Hello,
I''m seeing a lot of warnings in dmesg with a BTRFS filesystem. I''m using
the 3.1 kernel, I found a patch for these warnings (
http://marc.info/?l=linux-btrfs&m=131547325515336&w=2)
<http://marc.info/?l=linux-btrfs&m=131547325515336&w=2>, but that patch
has already been included in 3.1. Are there any other patches I can try?
I''m using
2011 May 23
5
Integration branch pushed out to btrfs-unstable
Hi everyone,
I''ve pushed out my current kernel git tree to a new branch called
integration-test. This is meant for integration testing only and should
not be run by anyone who doesn''t love crashes.
I''ve pulled together a lot of important work from a lot of different
people. It includes:
The new inode number allocator
Delayed inode and directory item updates
Scrub,
2011 Mar 31
4
[PATCH] Btrfs: fix free space cache when there are pinned extents and clusters
I noticed a huge problem with the free space cache that was presenting as an
early ENOSPC. Turns out when writing the free space cache out I forgot to take
into account pinned extents and more importantly clusters. This would result in
us leaking free space everytime we unmounted the filesystem and remounted it. I
fix this by making sure to check and see if the current block group has a
cluster
2007 Jun 29
2
Mknod: Operation not permitted
When trying to move my root to a btrfs filesystem, I found a missing
feature (or a bug). It's not possible to create device files. To
reproduce, run this on a btrfs filesystem:
mknod test c 1 1
result:
mknod: `test': Operation not permitted
Frank