On Tue, Mar 04, 2014 at 10:49:52AM +0800, Liu Bo wrote:
On Mon, Mar 03, 2014 at 03:25:28PM +0100, David Sterba wrote:
This should not be a hard failure, it can continue without RA for this
buffer. Besides, the RA buffer can be allocated at the beginning of send
operation and pointer stored
I have btrfs as the fs for a backuppc box. updatedb was running at the
same time as a massive rsync.
Mar 4 08:31:00 office-backup kernel: INFO: task updatedb.mlocat:903
blocked for more than 120 seconds.
Mar 4 08:31:00 office-backup kernel: Not tainted 3.13.2 #3
Mar 4 08:31:00
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/04/2014 09:19 AM, Mark Murawski wrote:
I have btrfs as the fs for a backuppc box. updatedb was running at
the same time as a massive rsync.
Mar 4 08:31:00 office-backup kernel: INFO: task
updatedb.mlocat:903 blocked for more than 120
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/15/2014 07:00 AM, Miao Xie wrote:
When we mounted the filesystem after the crash, we got the
following message: BTRFS error (device xxx): block group 4315938816
has wrong amount of free space BTRFS error (device xxx): failed to
load free
Hugo Mills hugo at carfax.org.uk writes:
This is just a guess, but you might have some large (1GB)
extents
in there that span across multiple chunks. I'd suggest running a
btrfs
defrag on any particularly big files and see if that helps the
situation.
Doing this is definitely helping,
On Mar 3, 2014, at 11:42 PM, Hendrik Friedel hend...@friedels.name wrote:
Hi Chris,
It might be worth finding large files to defragment. See the ENOSPC errors
during raid1 rebalance thread. It sounds like it might be possible for some
fragmented files to be stuck across multiple
On Mar 4, 2014, at 8:55 AM, Michael Russo m...@papersolve.com wrote:
Hugo Mills hugo at carfax.org.uk writes:
This is just a guess, but you might have some large (1GB)
extents
in there that span across multiple chunks. I'd suggest running a
btrfs
defrag on any particularly big files
Chris Murphy lists at colorremedies.com writes:
Based on my reading of the man page, I think it's expected.
You either need -s -l or -t.
Ok, although the man page uses [ ] instead of and something
does happen if I don't add them. But if I use -t 1 wouldn't that
get everything?
Now I've
On Mar 4, 2014, at 11:54 AM, Michael Russo m...@papersolve.com wrote:
Chris Murphy lists at colorremedies.com writes:
Based on my reading of the man page, I think it's expected.
You either need -s -l or -t.
Ok, although the man page uses [ ] instead of and something
does happen if I
I'm having difficulty getting a profile conversion from raid0 -
single to finish. Is there a way to tell the filesystem to stop all
new allocations for the raid0 profile, before the full balance
finishes? Otherwise I feel like I'm in a sisyphian push of blocks into
higher block numbers.
Since the
Remove unused variable in btrfs-image.c (update_super) and update man
page documentation about -r option. Running btrfsck on a restored
image produces missing chunk information. This is because by default,
btrfs-image fixes up chunk tree to use 1 stripe pointing to the
primary device. This in
Chris Murphy lists at colorremedies.com writes:
How can I find out what file is on the block group that
it's having a problem with?
I think that's btrfs-debug-tree -b ? But don't hold me to that.
I haven't done enough debugging to find files
from block numbers. Another that might be
Btrfs send reads data from disk and then writes to a stream via pipe or
a file via flush.
Currently we're going to read each page a time, so every page results
in a disk read, which is not friendly to disks, esp. HDD. Given that,
the performance can be gained by adding readahead for those pages.
On Mar 4, 2014, at 5:27 PM, Mike Russo m...@papersolve.com wrote:
Chris Murphy lists at colorremedies.com writes:
How can I find out what file is on the block group that
it's having a problem with?
I think that's btrfs-debug-tree -b ? But don't hold me to that.
I haven't done enough
14 matches
Mail list logo
