On Tue, 4 Mar 2014 10:19:20 -0500, Josef Bacik wrote:
> -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 amou
On Mar 4, 2014, at 5:27 PM, Mike Russo wrote:
> I'm sure this is due to the ext4 conversion, but that means the utility is
> making a btrfs filesystem that later can't be converted to another profile
> for some reason.
https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3
"But still,
On Mar 4, 2014, at 5:27 PM, Mike Russo wrote:
> Chris Murphy 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 f
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.
Chris Murphy 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 re
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 turns
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
On Mar 4, 2014, at 11:54 AM, Michael Russo wrote:
> Chris Murphy 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
Chris Murphy 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 8:55 AM, Michael Russo wrote:
> Hugo Mills 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
On Mar 3, 2014, at 11:42 PM, Hendrik Friedel 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 chunks, preventing
Hugo Mills 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, b
-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
-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
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 office-
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 s
16 matches
Mail list logo