rm /var/lib/btrfs/scrub-
On Fri, Apr 18, 2014 at 7:18 PM, Martin Steigerwald 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, running for 335 seconds
>
> 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
sp
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
> 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
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 :-)
)..
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 '{}' \;
a
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 http://vg
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
Mor
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
> s
> 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 Dun
> 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
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 string
12 matches
Mail list logo
