rm /var/lib/btrfs/scrub-bla-bla-bla-bla
On Fri, Apr 18, 2014 at 7:18 PM, Martin Steigerwald mar...@lichtvoll.de wrote:
Hello,
I have:
merkaba:/mnt#1 btrfs scrub status -d /home
scrub status for […]
scrub device /dev/dm-0 (id 1) status
scrub started at Fri Apr 18 17:48:10 2014,
Besides this, I'm still wondering about the changes in data security that
turning a database to NoCow would bring, i.e. would the data still be well
protected in case of a system crash or power failure ?
I have precious data in there and wouldn't like to jeopardize its security for
a
I would see one (dangerous? risky? needing more options perhaps?) solution:
dd if=/dev/sda of=/dev/sdb
/dev/sda: old disk
/dev/sdb: new disk
Maybe there is another much more complicated solution:
Plug the old disk in a USB dock/case, do the same for the new disk in
another dock/case, plug both
What makes the case complicate is
not the question how to preserve and copy the current data; it's how to
retain the historic data embodied in snapshots.
You can always rsync (incrementally with --link-dest) to another
place the sequence of snapshots, provided of course there is enough
space
Scenario: I had a subvolume with compression disabled and with many snapshots.
Then I decided to compress it retroactively with the following commands:
btrfs filesystem defragment -r -v -czlib /path
find /path -xdev -type d -print -exec btrfs filesystem
defragment -czlib '{}' \;
Thank you too for the enlightenment. Not just now but so many times in
the past (just the compilation of your list interventions is a wiki in
its own right).
Me too, I've been meaning to create a wiki account for quite some time
(but I was partly intimidated by the formality of the request :-)
Hi,
I think this issue came up recently. You can read more about it here:
http://comments.gmane.org/gmane.comp.file-systems.btrfs/33106
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at
I have been wondering the same thing for quite some time after having
read this post (which makes a pretty clear case in favour of ECC
RAM)...
hxxp://forums.freenas.org/threads/ecc-vs-non-ecc-ram-and-zfs.15449/
... and the ZFS on Linux FAQ
hxxp://zfsonlinux.org/faq.html#DoIHaveToUseECCMemory
Duncan,
As a silent reader of this list (for almost a year)...
As an anonymous supporter of the BAARF (Battle Against Any RAID
Four/Five/Six/ Z etc...) initiative...
I can only break my silence and applaud your frequent interventions
referring to N-Way mirroring (searching the list for the
claiming that RAID-10 (with 2-way mirroring) is guaranteed to survive
an arbitrary 2-device failure is incorrect.
Yes, you are right. I didn't mean any 2 devices. I should have
added from different mirrors :)
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body
How is a resilient 2 disk failure possible with four disk raid10?
__ ___ RAID0
__|__ __|__ ___ RAID1
| || |
AB CD
Loosing A+C / A+D / B+C / B+D is resilient.
Loosing A+B or C+D is catastrophic.
Sorry, it's my fault. In my urge to praise
Thanks Hugo,
Since:
-- i keep daily backups
-- all 4 devices are of the same size
I think I can test it (as soon as I have some time to spend in the
transition to BTRFS) and verify your assumptions (...and get my wish)
If you have an even number of devices and all the devices are the
12 matches
Mail list logo
