Signed-off-by: Augusto Mecking Caringi augustocari...@gmail.com
---
INSTALL | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/INSTALL b/INSTALL
index 8ead607..9a4ab64 100644
--- a/INSTALL
+++ b/INSTALL
@@ -12,9 +12,16 @@ complete:
modprobe libcrc32c
insmod
Dear list,
A tried to make a full defragmenting on my $HOME directory (which doesn't
contain any snapshots). After some hours of running, it stopped with „No space
left on device” error.
I checked and it ate about 50 GB of free space.
Before: Data, single: total=433.83GiB, used=~380.00GiB
Regression test for the btrfs ioctl clone operation when the source range
contains hole(s) and the FS has the NO_HOLES feature enabled (file holes
don't need file extent items in the btree to represent them).
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: fix clone to
If the NO_HOLES feature is enabled holes don't have file extent items in
the btree that represent them anymore. This made the clone operation
ignore the gaps that exist between consecutive file extent items and
therefore not create the holes at the destination.
A test case for xfstests follows.
Hi Arnd,
On Fri, 2014-05-30 at 22:01 +0200, Arnd Bergmann wrote:
[snip]
Arnd Bergmann (32):
fs: introduce new 'struct inode_time'
uapi: add struct __kernel_timespec{32,64}
fs: introduce sys_utimens64at
fs: introduce sys_newfstat64/sys_newfstatat64
arch: hook up new stat and
On Fri, May 30, 2014 at 10:01:24PM +0200, Arnd Bergmann wrote:
I picked this because it is a fairly isolated problem, as the
inode time stamps are rarely assigned to any other time values.
As a byproduct of this work, I documented for each of the file
systems we support how long the on-disk
If the NO_HOLES feature is enabled holes don't have file extent items in
the btree that represent them anymore. This made the clone operation
ignore the gaps that exist between consecutive file extent items and
therefore not create the holes at the destination.
A test case for xfstests follows.
Regression test for the btrfs ioctl clone operation when the source range
contains hole(s) and the FS has the NO_HOLES feature enabled (file holes
don't need file extent items in the btree to represent them).
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: fix clone to
On Saturday 31 May 2014 16:51:15 Richard Cochran wrote:
On Fri, May 30, 2014 at 10:01:24PM +0200, Arnd Bergmann wrote:
I picked this because it is a fairly isolated problem, as the
inode time stamps are rarely assigned to any other time values.
As a byproduct of this work, I documented
On Sat, May 31, 2014 at 05:23:02PM +0200, Arnd Bergmann wrote:
It's an approximation:
(Approximately never ;)
with 64-bit timestamps, you can represent close to 300 billion
years, which is way past the time that our planet can sustain
life of any form[1].
Did you mean mean 64 bits worth
Chris,
Thanks for the continued help. I had to put the recovery on hiatus
while I waited for new hard drives to be delivered. I never was able
to figure out how to replace the failed drive, but I did learn a lot
about how Btrfs works. The approach to doing practically all
operations with file
Typically they are using 64-bit signed seconds.
On May 31, 2014 11:22:37 AM PDT, Richard Cochran richardcoch...@gmail.com
wrote:
On Sat, May 31, 2014 at 05:23:02PM +0200, Arnd Bergmann wrote:
It's an approximation:
(Approximately never ;)
with 64-bit timestamps, you can represent close to
Michael,
btrfs-send doesn't really know or care how did you manage to get from
a to c. It is able to compare any two RO subvolumes (not necessarily
related by snapshot operations), and produce a stream of commands that
transfer a-content into c-content.
Send assumes that at a receive side, you
On Tue, May 20, 2014 at 03:30:48PM +, Holger Hoffstätte wrote:
As Marc Merlin recently wrote in his blog [1] scrub can sometimes leave a
stale state file behind, making cancel/resume complain. I took a peek at
the code and found most of the scrub state file handling fairly
will be compressed with LZ4.
Usage:
Apply the following 8 patches to the current git tree
(as of 20140531) and compile/load the btrfs module.
# mount -t btrfs -o compress=lz4 device mountpoint
or
# mount -t btrfs -o compress-force=lz4 device mountpoint
Philip Worrall (8):
Btrfs: Add kernel config options
Add lz4.c to the btrfs makefile
Signed-off-by: Philip Worrall philip.worr...@googlemail.com
---
fs/btrfs/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/Makefile b/fs/btrfs/Makefile
index f341a98..af8d12d 100644
--- a/fs/btrfs/Makefile
+++
Signed-off-by: Philip Worrall philip.worr...@googlemail.com
---
fs/btrfs/disk-io.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 6d1ac7d..56bab54 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -2479,7 +2479,8 @@
Signed-off-by: Philip Worrall philip.worr...@googlemail.com
---
fs/btrfs/compression.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/compression.h b/fs/btrfs/compression.h
index 0c803b4..c39b86a 100644
--- a/fs/btrfs/compression.h
+++ b/fs/btrfs/compression.h
@@
Add functions to handle lz4 compression and decompression and
include them within a new btrfs_compression_op struct.
Signed-off-by: Philip Worrall philip.worr...@googlemail.com
---
fs/btrfs/lz4.c | 436 +
1 file changed, 436 insertions(+)
Add lz4 compression structure to available btrfs compression
operations.
Signed-off-by: Philip Worrall philip.worr...@googlemail.com
---
fs/btrfs/compression.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
index ed1ff1c..35b3268 100644
---
Check whether the user has set compress=lz4 in the mount options
and if so set the compress method to lz4.
Signed-off-by: Philip Worrall philip.worr...@googlemail.com
---
fs/btrfs/super.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/super.c
Add two kernel configuration options for LZ4 compress
and decompress.
Signed-off-by: Philip Worrall philip.worr...@googlemail.com
---
fs/btrfs/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
index a66768e..fb93d9e 100644
--- a/fs/btrfs/Kconfig
Add various feature flags for LZ4 so that older kernels refuse
to mount btrfs filesystems that have been used with LZ4
Signed-off-by: Philip Worrall philip.worr...@googlemail.com
---
fs/btrfs/ctree.h | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/ctree.h
If the NO_HOLES feature is enabled holes don't have file extent items in
the btree that represent them anymore. This made the clone operation
ignore the gaps that exist between consecutive file extent items and
therefore not create the holes at the destination. When not using the
NO_HOLES feature,
On 2014/05/31 12:00 AM, Martin wrote:
OK... I'll jump in...
On 30/05/14 21:43, Josef Bacik wrote:
[snip]
Option 1: Only relink inodes that haven't changed since the snapshot was
taken.
Pros:
-Faster
-Simpler
-Less duplicated code, uses existing functions for tricky operations so
less likely
Szőts Ákos posted on Sat, 31 May 2014 09:19:03 +0200 as excerpted:
A tried to make a full defragmenting on my $HOME directory (which
doesn't contain any snapshots). After some hours of running, it stopped
with „No space left on device” error.
I checked and it ate about 50 GB of free space.
Brendan Hide posted on Sun, 01 Jun 2014 01:51:49 +0200 as excerpted:
Will option one mean that we always need to mount with noatime or
read-only to allow snapshot defragging to do anything?
That is a very good question. I very rarely have mounts without noatime
- and usually only because I
Duncan posted on Sun, 01 Jun 2014 00:56:09 + as excerpted:
As for reclaiming the space...
One more option there I forgot to mention... There are various dedup
tools out there. See the wiki ( https://btrfs.wiki.kernel.org ) and the
list archive for more as I've not used any of them
at some point, my /home randomly(?) went into -ro as i noticed writes
were not working. Checked dmesg which had some backtraces which i
ignored. So I simply rebooted, only to find out it wouldn't come back.
so now my /home is stuck on here, I was literally going to do my round
of backups tonight.
On Sat, May 31, 2014 at 05:23:02PM +0200, Arnd Bergmann wrote:
On Saturday 31 May 2014 16:51:15 Richard Cochran wrote:
Why are some of the time stamp expiration dates marked as never?
It's an approximation:
Also, the term never might mean using arbitrarily long integers
as in ASN.1.
On Sat, May 31, 2014 at 12:34:12PM -0700, H. Peter Anvin wrote:
Typically they are using 64-bit signed seconds.
Okay, that is what I wanted to know.
Thanks,
Richard
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More
31 matches
Mail list logo
