'btrfs scan' uses libblkid to scan devices by default, and libblkid uses
cache to reduce the probe.
But if operations below is done in less than 2 seconds(BLKID_PROBE_MIN),
'btrfs scan' will still use the uncorrect cache and scan on the deleted device.
0. /dev/sda[1-4] mounted on /mnt using
On 04/10/2014 03:30 PM, Qu Wenruo wrote:
'btrfs scan' uses libblkid to scan devices by default, and libblkid uses
cache to reduce the probe.
But if operations below is done in less than 2 seconds(BLKID_PROBE_MIN),
'btrfs scan' will still use the uncorrect cache and scan on the deleted
Thanks Duncan for the perfect explanations.
From this, I understand that I might get both better performance by setting my
akonadi dir to nocow, and still be able to take a snapshot from time to
time, which is exactly what I need.
Besides this, I'm still wondering about the changes in data
On 10/4/2014 6:48 πμ, Liu Bo wrote:
Hello,
This the 10th attempt for in-band data dedupe, based on Linux _3.14_ kernel.
Data deduplication is a specialized data compression technique for eliminating
duplicate copies of repeating data.[1]
This patch set is also related to Content based storage
SMART indicates that my notebook disk may soon be failing (an
unreadable/uncorrectable sector), therefore I intend to exchange it. The
disk contains a single btrfs filesystem with several nested(!)
subvolumes, each with several read-only snapshots in a .snapshots
subdirectory.
As far as I
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
Michael Schuerig posted on Thu, 10 Apr 2014 15:21:01 +0200 as excerpted:
SMART indicates that my notebook disk may soon be failing (an
unreadable/uncorrectable sector), therefore I intend to exchange it. The
disk contains a single btrfs filesystem with several nested(!)
subvolumes, each with
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
On Thursday 10 April 2014 13:58:45 Duncan wrote:
Michael Schuerig posted on Thu, 10 Apr 2014 15:21:01 +0200 as
excerpted:
SMART indicates that my notebook disk may soon be failing (an
unreadable/uncorrectable sector), therefore I intend to exchange it.
The disk contains a single btrfs
Hi again,
So it seems performance issues caused by FS degredation are in the
current development stage of btrfs not getting a lot of attention.
Hopefully production use on facebook servers will expose one or
another issue and with the developers being employed there chances are
good btrfs will
On Thu, Apr 10, 2014 at 12:08:17PM +0300, Konstantinos Skarlatos wrote:
On 10/4/2014 6:48 πμ, Liu Bo wrote:
Hello,
This the 10th attempt for in-band data dedupe, based on Linux _3.14_ kernel.
Data deduplication is a specialized data compression technique for
eliminating
duplicate copies
On Thursday 10 April 2014 15:15:02 Duncan wrote:
Meanwhile (2), given the existence of those tested backups, there's
yet another way to accomplish things. Simply restore from the
backups the same way you would if the working copy went down and you
had to restore it, only restore to the new
Hi,
Just FYI, these patches are also available on the following site,
kernel:
https://github.com/liubogithub/btrfs-work.git dedup-on-3.14-linux
progs:
https://github.com/liubogithub/btrfs-progs.git dedup
thanks,
-liubo
On Thu, Apr 10, 2014 at 11:48:30AM +0800, Liu Bo wrote:
Hello,
This
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
On Thursday 10 April 2014 18:01:31 George Eleftheriou wrote:
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
So, since then I found out in the thread
Subject: Re: btrfs on 3.14rc5 stuck on btrfs_tree_read_lock sync
that my btrfs filesystem has a clear problem, which Josef and Chris are
still looking into.
Basically, I've had btrfs near deadlocks on this filesystem:
INFO: task
Dne Čt 10. dubna 2014 15:21:01, Michael Schuerig napsal(a):
SMART indicates that my notebook disk may soon be failing (an
unreadable/uncorrectable sector), therefore I intend to exchange it. The
disk contains a single btrfs filesystem with several nested(!)
subvolumes, each with several
Am Donnerstag, 10. April 2014, 17:51:26 schrieb Michael Schuerig:
On Thursday 10 April 2014 15:15:02 Duncan wrote:
Meanwhile (2), given the existence of those tested backups, there's
yet another way to accomplish things. Simply restore from the
backups the same way you would if the
On Thursday 10 April 2014 19:17:13 Jan Kouba wrote:
Dne Čt 10. dubna 2014 15:21:01, Michael Schuerig napsal(a):
SMART indicates that my notebook disk may soon be failing (an
unreadable/uncorrectable sector), therefore I intend to exchange it.
The disk contains a single btrfs filesystem with
On Thu, Apr 10, 2014 at 01:00:35PM -0700, Chip Turner wrote:
I have a filesystem that I can't seem to resolve ENOSPC issues. No
write operation can succeed; I've tried the wiki's suggestions
(balancing, which fails because of ENOSPC, mounting with nodatacow,
clear_cache, nospace_cache,
Dne Čt 10. dubna 2014 20:36:32, Michael Schuerig napsal(a):
On Thursday 10 April 2014 19:17:13 Jan Kouba wrote:
Dne Čt 10. dubna 2014 15:21:01, Michael Schuerig napsal(a):
SMART indicates that my notebook disk may soon be failing (an
unreadable/uncorrectable sector), therefore I intend to
On Thu, Apr 10, 2014 at 1:34 PM, Hugo Mills h...@carfax.org.uk wrote:
On Thu, Apr 10, 2014 at 01:00:35PM -0700, Chip Turner wrote:
btrfs show:
Label: none uuid: 04283a32-b388-480b-9949-686675fad7df
Total devices 1 FS bytes used 135.58GiB
devid1 size 238.22GiB used 238.22GiB path
Michael Schuerig posted on Thu, 10 Apr 2014 18:24:00 +0200 as excerpted:
I *think* send/receive with clone sources might be the key to a
solution. I'm still hoping that someone with a far better understanding
of btrfs than me gives it a try first...
Well, there's both that (which I don't know
Chip Turner posted on Thu, 10 Apr 2014 15:40:22 -0700 as excerpted:
On Thu, Apr 10, 2014 at 1:34 PM, Hugo Mills h...@carfax.org.uk wrote:
On Thu, Apr 10, 2014 at 01:00:35PM -0700, Chip Turner wrote:
btrfs show:
Label: none uuid: 04283a32-b388-480b-9949-686675fad7df
Total devices 1 FS bytes
Add device management related paragraph to better explain btrfs device
management.
Cc: Marc MERLIN m...@merlins.org
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
Documentation/btrfs-balance.txt | 3 +++
Documentation/btrfs-device.txt | 42 +
Add more explain on btrfs-zero-log about when to use it.
Cc: Marc MERLIN m...@merlins.org
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
Documentation/btrfs-zero-log.txt | 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/btrfs-zero-log.txt
PTR_RET is deprecated. Do not recommend its usage anymore.
Use PTR_ERR_OR_ZERO instead.
Signed-off-by: Duan Jiong duanj.f...@cn.fujitsu.com
---
fs/btrfs/hash.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/fs/btrfs/hash.c b/fs/btrfs/hash.c
index 85889aa..8c2d3b9 100644
On Tue, Apr 08, 2014 at 09:42:03AM +0800, Qu Wenruo wrote:
I had debian add this to the initramfs initrd by default so that someone
can recover their root filesystem with this command if it won't mount.
What got fixed is the kernel used to oops and crash, and now it gives a
nice can't mount
28 matches
Mail list logo
