Hi there!
Another challenge...
I'm using btrfs. So i make snapshots from my system. And in a script, I
make a symlink (for example: @system.CURRENT and @system.LAST) for the
current and the last snapshot.
So i want to add 2 entries in grub2 from which i can boot into the
current and the
On 2014-11-19 23:48, Jakob Schürz wrote:
Hi there!
Another challenge... I'm using btrfs. So i make snapshots from my
system. And in a script, I make a symlink (for example:
@system.CURRENT and @system.LAST) for the current and the last
snapshot.
Interesting, I was unaware that I could
Am 2014-11-20 um 11:17 schrieb Goffredo Baroncelli:
On 2014-11-19 23:48, Jakob Schürz wrote:
Hi there!
Another challenge... I'm using btrfs. So i make snapshots from my
system. And in a script, I make a symlink (for example:
@system.CURRENT and @system.LAST) for the current and the last
On Thu, 6 Nov 2014 10:19:54 -0500, Josef Bacik wrote:
If we have two fsync()'s race on different subvols one will do all of its work
to get into the log_tree, wait on it's outstanding IO, and then allow the
log_tree to finish it's commit. The problem is we were just free'ing that
subvols
the following four subvolumes
/root/
/root/etc
/root/usr
/root/var
When you need to snapshot, you should:
# btrfs subvolume snapshot /root /backup-root-20141120
# btrfs subvolume snapshot /root/etc /backup-root-20141120/etc
# btrfs subvolume snapshot /root/usr /backup-root-20141120/usr
# btrfs
Am Wed, 19 Nov 2014 16:58:16 +0100
schrieb Jakob Schürz wertsto...@nurfuerspam.de:
Hi there!
I'm new on btrfs, and I like it :)
Me too :) . (I've been using it since May.)
But i have a question. I have a existing backup on an external HDD. This
was ext4 before i converted it to btrfs.
On 2014-11-19 16:58, Jakob Schürz wrote:
Hi there!
I'm new on btrfs, and I like it :)
But i have a question. I have a existing backup on an external HDD. This
was ext4 before i converted it to btrfs.
And i installed my debian new on btrfs with some subvolumes. (f.e. home,
var,
Bardur Arantsson posted on Thu, 20 Nov 2014 14:17:52 +0100 as excerpted:
If you have no other backups, I would really recommend that you *don't*
use btrfs for your backup, or at least have a *third* backup which isn't
on btrfs -- there are *still* problems with btrfs that can potentially
Hi! Trying to do a btrfs send, and failing with:
root@khamul:~# btrfs send /biggie/BACKUP/ | btrfs receive /tmp/sdd1/
At subvol /biggie/BACKUP/
At subvol BACKUP
ERROR: rename o2046806-17126-0 - volumes/ccdn-ch2-01 failed. No such
file or directory
Judging by disk capacity, it hits this about
On Thu, Nov 20, 2014 at 11:57:50AM -0500, Ken D'Ambrosio wrote:
Hi! Trying to do a btrfs send, and failing with:
root@khamul:~# btrfs send /biggie/BACKUP/ | btrfs receive /tmp/sdd1/
At subvol /biggie/BACKUP/
At subvol BACKUP
ERROR: rename o2046806-17126-0 - volumes/ccdn-ch2-01 failed. No
On 2014-11-20 12:11, Hugo Mills wrote:
On Thu, Nov 20, 2014 at 11:57:50AM -0500, Ken D'Ambrosio wrote:
Hi! Trying to do a btrfs send, and failing with:
root@khamul:~# btrfs send /biggie/BACKUP/ | btrfs receive /tmp/sdd1/
At subvol /biggie/BACKUP/
At subvol BACKUP
ERROR: rename
On Thu, Nov 20, 2014 at 4:14 AM, Goffredo Baroncelli kreij...@inwind.it wrote:
Supposing to have the following four subvolumes
/root/
/root/etc
/root/usr
/root/var
When you need to snapshot, you should:
# btrfs subvolume snapshot /root /backup-root-20141120
# btrfs subvolume snapshot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/19/2014 5:25 PM, Robert White wrote:
The controller, the thing that sets the ready bit and sends the
interrupt is distinct from the driver, the thing that polls the
ready bit when the interrupt is sent. At the bus level there are
fixed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/19/2014 5:33 PM, Robert White wrote:
That would be fake raid, not hardware raid.
The LSI MegaRaid controller people would _love_ to hear more about
your insight into how their battery-backed multi-drive RAID
controller is fake. You should
On Thu, Nov 13, 2014 at 02:18:21AM -0800, Omar Sandoval wrote:
The RCU-friendly string API used internally by BTRFS is generic enough for
common use. This doesn't add any new functionality, but instead just moves the
code and documents the existing API.
Reviewed-by: Josh Triplett
On 11/20/2014 12:26 PM, Phillip Susi wrote:
Yes, ACPI 4.0 added this mess. I have yet to see a single system that
actually implements it. I can't believe they even bothered adding
this driver to the kernel. Is there anyone in the world who has ever
used it? If no motherboard vendor has
On 11/20/2014 12:34 PM, Phillip Susi wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/19/2014 5:33 PM, Robert White wrote:
That would be fake raid, not hardware raid.
The LSI MegaRaid controller people would _love_ to hear more about
your insight into how their battery-backed
I have changed file system label few times in total. When I tried
to mount it after that, it became not mountable:
# mount /dev/sdb1 /mnt
mount: Not a directory
In dmesg I see the following after above command:
[ 5198.413202] BTRFS info (device sdb1): disk space caching is enabled
[
On Thu, Nov 20, 2014 at 6:27 PM, Boris Chernov aqs1...@hotmail.com wrote:
Since it failed after checking extents I decided to try
--init-extent-tree:
There might be hope yet if you didn't use --repair which is said on
the wiki and many times on this list is kindof a last resort. But at
the
On Mon, Nov 17, 2014 at 08:04:05PM +0100, Goffredo Baroncelli wrote:
On 2014-11-17 07:59, Brendan Hide wrote:
That leaves two aspects of this issue which I view as two separate bugs:
a) Btrfs cannot gracefully handle separate filesystems that have the same
UUID. At all.
b) Grub
On Wed, Nov 19, 2014 at 10:20:17AM -0500, Phillip Susi wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 9:54 PM, Chris Murphy wrote:
Why is it silly? Btrfs on a thin volume has practical use case
aside from just being thinly provisioned, its snapshots are block
device
On Fri, 21 Nov 2014 01:27:17 +
Boris Chernov aqs1...@hotmail.com wrote:
I have changed file system label few times in total. When I tried
to mount it after that, it became not mountable:
# mount /dev/sdb1 /mnt
mount: Not a directory
I'd say that implies something is wrong with
On Wed, Nov 19, 2014 at 09:33:31AM -0600, Eric Sandeen wrote:
A couple tests exercise replace but were not marked as such
in the group file.
Hi Eric,
I have a patch sitting in my git tree that adds most of btrfs tests in
one or more groups, I'll send it out for review soon.
Thanks,
Eryu
Some new btrfs groups have been added in the btrfs stress patchset add
other tests to proper groups too.
Signed-off-by: Eryu Guan eg...@redhat.com
---
tests/btrfs/group | 110 +++---
1 file changed, 55 insertions(+), 55 deletions(-)
diff --git
On Tue, Nov 18, 2014 at 09:29:54AM +0200, Brendan Hide wrote:
Hey, guys
See further below extracted output from a daily scrub showing csum
errors on sdb, part of a raid1 btrfs. Looking back, it has been
getting errors like this for a few days now.
The disk is patently unreliable but
On Nov 20, 2014, at 10:44 PM, Eryu Guan eg...@redhat.com wrote:
On Wed, Nov 19, 2014 at 09:33:31AM -0600, Eric Sandeen wrote:
A couple tests exercise replace but were not marked as such
in the group file.
Hi Eric,
I have a patch sitting in my git tree that adds most of btrfs tests in
On 2014/11/21 06:58, Zygo Blaxell wrote:
You have one reallocated sector, so the drive has lost some data at some
time in the last 49000(!) hours. Normally reallocations happen during
writes so the data that was lost was data you were in the process of
overwriting anyway; however, the
27 matches
Mail list logo
