On 2018年05月20日 07:40, Steve Leung wrote:
> On 05/17/2018 11:49 PM, Qu Wenruo wrote:
>> On 2018年05月18日 13:23, Steve Leung wrote:
>>> Hi list,
>>>
>>> I've got 3-device raid1 btrfs filesystem that's throwing up some
>>> "corrupt leaf" errors in dmesg. This is a uniquified list I've
>>> observed
On 05/17/2018 11:49 PM, Qu Wenruo wrote:
On 2018年05月18日 13:23, Steve Leung wrote:
Hi list,
I've got 3-device raid1 btrfs filesystem that's throwing up some
"corrupt leaf" errors in dmesg. This is a uniquified list I've
observed lately:
Evidently I forgot that I added a fourth device to this
I have let the find root command run for 14+ days, its produced a
pretty huge log file 1.6 GB but still hasn't completed. I think I will
start the process of reformatting my drives and starting over.
Thanks for your help anyway.
Kind regards
Michael
On 5 May 2018 at 01:43, Qu Wenruo
On sabato 19 maggio 2018 01:55:30 CEST, Tomasz Pala wrote:
The "defrag only not-snapshotted data" mode would be enough for many
use cases and wouldn't require more RAM. One could run this before
taking a snapshot and merge _at least_ the new data.
snapper users with hourly snapshots will not
On venerdì 18 maggio 2018 20:33:53 CEST, Austin S. Hemmelgarn wrote:
With a bit of work, it's possible to handle things sanely. You
can deduplicate data from snapshots, even if they are read-only
(you need to pass the `-A` option to duperemove and run it as
root), so it's perfectly reasonable
