On Fri, Apr 11, 2014 at 10:43:53AM +0800, Qu Wenruo wrote:
> Add more explain on btrfs-zero-log about when to use it.
>
> Cc: Marc MERLIN
> Signed-off-by: Qu Wenruo
Reviewed-by: Marc MERLIN
Looks good, thank you.
Marc
> ---
> Documentation/btrfs-zero-log.txt | 18 ++
> 1 fi
Thank you for the extremely detailed and helpful reply. I now
understand what was happening. To me, when I read "total=" I guess I
thought that was capacity rather than allocated (but now "holey")
chunks. I agree that perhaps adjusting the phrasing of the output of
df and show would be helpful i
On Fri, Apr 11, 2014 at 10:43:52AM +0800, Qu Wenruo wrote:
> Add device management related paragraph to better explain btrfs device
> management.
Thank you for these updates.
> Cc: Marc MERLIN
> Signed-off-by: Qu Wenruo
(comments below)
> ---
> Documentation/btrfs-balance.txt | 3 +++
> Do
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 "ca
PTR_RET is deprecated. Do not recommend its usage anymore.
Use PTR_ERR_OR_ZERO instead.
Signed-off-by: Duan Jiong
---
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
--- a/fs/btrfs/hash.c
+++
Add more explain on btrfs-zero-log about when to use it.
Cc: Marc MERLIN
Signed-off-by: Qu Wenruo
---
Documentation/btrfs-zero-log.txt | 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/btrfs-zero-log.txt b/Documentation/btrfs-zero-log.txt
index e3041fa..a8e4d
Add device management related paragraph to better explain btrfs device
management.
Cc: Marc MERLIN
Signed-off-by: Qu Wenruo
---
Documentation/btrfs-balance.txt | 3 +++
Documentation/btrfs-device.txt | 42 +
Documentation/btrfs-replace.txt | 4
3
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 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 13
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 kn
On 04/08/2014 07:18 AM, Wang Shilong wrote:
Steps to reproduce:
# mkfs.btrfs -f /dev/sda[8-11] -m raid5 -d raid5
# mount /dev/sda8 /mnt
# btrfs scrub start -BR /mnt
# echo $? <--unverified errors make return value be 3
This is because we don't setup right mapping between physical
and l
On Thu, Apr 10, 2014 at 1:34 PM, Hugo Mills 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 /dev/sdb2
>>
>> bt
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 i
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, eno
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, enospc_debug, truncating files, deleting
files, briefly microwaving 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 filesyste
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
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 rea
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 btrfs-transacti:
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
>
> 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
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
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 ne
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
> >du
George Eleftheriou posted on Thu, 10 Apr 2014 16:00:06 +0200 as excerpted:
> 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 docks/cases in another linux system running
> recent kernel
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 han
Swâmi Petaramesh posted on Thu, 10 Apr 2014 10:22:15 +0200 as excerpted:
> 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 ex
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 btrf
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
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 wi
> 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
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 can
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
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 s
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 device
'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 single
35 matches
Mail list logo
