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
Mo
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 A
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.
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 myself
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 beca
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 spa
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 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. When not using the
NO_HOLES feature,
Add lz4 compression structure to available btrfs compression
operations.
Signed-off-by: Philip Worrall
---
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
--- a/fs/btrfs/compression.c
+++ b/f
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
---
fs/btrfs/super.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index d4878dd..a34873
Add two kernel configuration options for LZ4 compress
and decompress.
Signed-off-by: Philip Worrall
---
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
+++ b/fs/btrfs/Kconfig
@@ -6,6 +
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
---
fs/btrfs/ctree.h | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index d8a66
Add lz4.c to the btrfs makefile
Signed-off-by: Philip Worrall
---
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
+++ b/fs/btrfs/Makefile
@@ -6,7 +6,7 @@ btrfs-y += s
Signed-off-by: Philip Worrall
---
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 @@ int open_ctree(struct super_bloc
Signed-off-by: Philip Worrall
---
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
@@ -77,5 +77,5 @@ struct btrfs_compr
Add functions to handle lz4 compression and decompression and
include them within a new btrfs_compression_op struct.
Signed-off-by: Philip Worrall
---
fs/btrfs/lz4.c | 436 +
1 file changed, 436 insertions(+)
create mode 100644 fs/btrfs/lz
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
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
> straightfo
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 hav
Typically they are using 64-bit signed seconds.
On May 31, 2014 11:22:37 AM PDT, Richard Cochran
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 300 billion
>>
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 syst
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 wor
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 docu
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 d
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.
S
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-d
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 a
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.
S
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 d
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
After
30 matches
Mail list logo