On 10/20/2015 15:59 -0400, Austin S Hemmelgarn wrote:
>> .
>> With a 32-bit checksum and a 4k block (the math is easier with
>> smaller numbers), that's 4128 bits, which means that a random
>> single bit error will have a approximately 0.24% chance of
>> occurring
On 08/16/2016 16:33 -0700, Rakesh Sankeshi wrote:
>> also is there any timeframe on when the qgroup / quota issues would be
>> stabilized in btrfs?
>>
>> Thanks!
This may or may not be of interest to you, but for the record, since at least
linux 4.2, I've had pretty good
On 09/15/2016 15:18 -0600, Chris Murphy wrote:
>> > System, single: total=4.00MiB, used=0.00B
>> > Metadata, RAID1: total=10.00GiB, used=8.14GiB
>> > GlobalReserve, single: total=512.00MiB, used=0.00B
>>
>> btrfs balance start -mconvert=raid1,soft
Since the single
On 09/17/2016 09:34 -0500, Walberg, Tim wrote:
>> On 09/15/2016 15:18 -0600, Chris Murphy wrote:
>> >> > System, single: total=4.00MiB, used=0.00B
>> >> > Metadata, RAID1: total=10.00GiB, used=8.14GiB
>> >> > GlobalReserve, single: total=512.00MiB, used=0.00B
>>
Just updated my kernel and btrfs-tools to 4.8.1 and now it seems
that "btrfs quota rescan -w " does not in fact wait
for the rescan to finish. Running it a second time immediately
after does, however.
Was this an intentional change, or is it a regression/bug?
--
twalb...@gmail.com,
Unless I'm misinterpreting something it appears that maybe btrfs doesn't pass
fstrim commands down to the underlying drives when being used in a RAID-1
config.
I have this output from a small script I wrote to run at boot time (and also via
cron.weekly), rather than using continous trim in the
Forgot to mention - this was on a rather crusty 4.2.6 kernel. Just upgraded to
4.8.1
and the issue appears to have been resolved...
On 10/18/2016 12:42 -0500, Walberg, Tim wrote:
>> Unless I'm misinterpreting something it appears that maybe btrfs
>> doesn't pass
>> fstrim commands
All -
I have a file system I'm having some issues with. The initial symptoms were
that mount
would run for several hours, either committing or rolling back transactions
(primarily
due to a balance that was running when the system was rebooted for other
reasons -
the skip_balance mount option
