On Mon, May 05, 2014 at 03:24:45AM +, Duncan wrote:
*However*: snapshotting a read-only snapshot and making the new one
writable is easy enough[1]. Just keep the originals read-only so they
can be used as parents/clones, and make a second, writable snapshot of
the first, to do your
Thanks for working on this.
I am running some tests will let you know.
Anand
On 05/06/2014 02:33 PM, Qu Wenruo wrote:
Old btrfs can't find a missing btrfs device since there is no
mechanism for block layer to inform fs layer.
But we can use a workaround that only check status(by using
On Tue, May 06, 2014 at 08:10:00PM +, Duncan wrote:
Marc MERLIN posted on Sun, 04 May 2014 22:50:29 -0700 as excerpted:
In the second FS:
Label: btrfs_pool1 uuid: [...]
Total devices 1 FS bytes used 442.17GiB
devid1 size 865.01GiB used 751.04GiB path [...]
The
Original Message
Subject: Re: [RFC PATCH 1/2] btrfs: Add missing device check in
dev_info/rm_dev ioctl
From: Anand Jain anand.j...@oracle.com
To: Qu Wenruo quwen...@cn.fujitsu.com
Date: 2014年05月07日 16:00
Thanks for working on this.
I am running some tests will let you
Hi Chris and other devs,
Does it really make sense to turn off -mdup on SSDs? I would argue that
no. In my case dmcrypt protected me from that, so I'm happy, but even if
I didn't use it, I'd want the protection of -mdup, even if the
protection mght only be partial.
On Tue, May 06, 2014 at
On Wed, May 07, 2014 at 01:18:40AM -0700, Marc MERLIN wrote:
On Tue, May 06, 2014 at 07:39:12PM +, Duncan wrote:
That appears to be a very good use of either -d raid0 or -d single, yes.
And since you're apparently not streaming such high resolution video that
you NEED the raid0,
On Wed, May 07, 2014 at 09:29:41AM +0100, Hugo Mills wrote:
On Wed, May 07, 2014 at 01:18:40AM -0700, Marc MERLIN wrote:
On Tue, May 06, 2014 at 07:39:12PM +, Duncan wrote:
That appears to be a very good use of either -d raid0 or -d single, yes.
And since you're apparently not
On Tue, May 06, 2014 at 04:26:48PM +, Duncan wrote:
Marc MERLIN posted on Sun, 04 May 2014 22:04:59 -0700 as excerpted:
On Mon, May 05, 2014 at 01:36:39AM +0100, Hugo Mills wrote:
I'm guessing it involves reflink copies of files from the snapshot
back to the original, and then
On Tue, May 06, 2014 at 09:02:46AM +0200, john terragon wrote:
just one last doubt:
why do you use --align-payload=1024? (or 8912)
Cryptsetup man says that the default for the payload alignment is 2048
(512-byte sectors). So, it's already aligned by default to 4K-byte
physical sectors (if
On 2014/05/07 09:59 AM, Marc MERLIN wrote:
[snip]
Did I get this right?
I'm not sure I did, since it seems the bigger the -dusage number, the
more work balance has to do.
If I asked -dsuage=85, it would do all chunks that are more than 15%
full?
-dusage=85 balances all chunks that up to 85%
On Mon, May 05, 2014 at 02:12:30AM +, Duncan wrote:
Marc MERLIN posted on Sat, 03 May 2014 17:47:32 -0700 as excerpted:
Just as an FYI, like (likely) most subscribers, I do prefer Cc on
replies. Without that, I'm much less likely to see your message timely,
or at all if I'm behind on Email.
Signed-off-by: Liu Bo bo.li@oracle.com
---
crypto/testmgr.c | 10 ++
crypto/testmgr.h | 33 +
2 files changed, 43 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index dc3cf35..27ba702 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
xxHash is an extremely fast non-cryptographic Hash algorithm, working at speeds
close to RAM limits.[1] And xxhash is 32-bits hash, same as crc32.
This modifies btrfs's checksum API a bit and adopts xxhash as an alternative
checksum algorithm.
Note: We needs to update btrfs-progs side as well
From: root root@localhost.localdomain
Signed-off-by: Liu Bo bo.li@oracle.com
---
Makefile |4 +-
crc32c.h |4 +-
disk-io.c |2 +-
hash.h|2 +-
xxhash.c | 448 +
xxhash.h | 171 +++
6
This will be used in btrfs, and maybe in others in the future.
Signed-off-by: Liu Bo bo.li@oracle.com
---
crypto/Kconfig | 7 +
crypto/Makefile | 1 +
crypto/xxhash.c | 383
include/crypto/xxhash.h | 209
xxHash is an extremely fast non-cryptographic Hash algorithm, working at speeds
close to RAM limits.[1] And xxhash is 32-bits hash, same as crc32.
Here is the hash comparsion extracted from the link[1]:
(single thread, Windows Seven 32 bits, using Open Source's SMHasher on a Core 2
Duo @3GHz)
On Wed, May 07, 2014 at 06:56:29PM +0800, Liu Bo wrote:
xxHash is an extremely fast non-cryptographic Hash algorithm, working at
speeds
close to RAM limits.[1] And xxhash is 32-bits hash, same as crc32.
Here is the hash comparsion extracted from the link[1]:
(single thread, Windows Seven
Russell Coker posted on Wed, 07 May 2014 15:36:15 +1000 as excerpted:
How could BTRFS and a database fight about data recovery?
BTRFS offers similar guarantees about data durability etc to other
journalled filesystems and only differs by having checksums so that
while a snapshot might have
When we have non-inlined extent references, we were failing to find the
corresponding extent item for an existing csum item in the csum tree.
Reproducer:
mkfs.btrfs -f /dev/sdd
mount /dev/sdd /mnt
xfs_io -f -c falloc 780366 135302 /mnt/foo
xfs_io -c falloc 327680 151552 /mnt/foo
So have others found a good way to have an idea about how much space is
taken by each snapshot?
I've tried quota trees, but I'm not sure how to read the output, or if it's
correct (including the negative numbers some have mentioned). Are there
other options?
I think the main problem is that the
Marc MERLIN posted on Wed, 07 May 2014 01:56:12 -0700 as excerpted:
On Tue, May 06, 2014 at 04:26:48PM +, Duncan wrote:
Marc MERLIN posted on Sun, 04 May 2014 22:04:59 -0700 as excerpted:
Aaah, right, you can use a script to see the file differences between
two snapshots, and then
On Wed, May 07, 2014 at 11:35:52AM +, Duncan wrote:
Marc MERLIN posted on Wed, 07 May 2014 01:56:12 -0700 as excerpted:
On Tue, May 06, 2014 at 04:26:48PM +, Duncan wrote:
Marc MERLIN posted on Sun, 04 May 2014 22:04:59 -0700 as excerpted:
Aaah, right, you can use a script
With kernel commit 00fdf13a2e9f313a044288aa59d3b8ec29ff904a, the first
clone-range overwrite attempt now fails with EOPNOTSUPP, rather than
tripping a Btrfs BUG_ON().
This test now trips a new Btrfs bug, in which EIO is returned for
subsequent reads following the second clone range ioctl.
Marc MERLIN posted on Wed, 07 May 2014 03:55:51 -0700 as excerpted:
subvolumes are also used as units of backup for btrfs send.
Hmm, yes. Thanks. I don't use send/receive here so forgot about that.
So my vote would be, for example (modified slightly for posting from my
own mounts):
On Wed, 7 May 2014 04:30:30 -0700
Marc MERLIN m...@merlins.org wrote:
-dusage=85 balances all chunks that up to 85% full. The higher the
number, the more work that needs to be done.
Aah, right. I see why it's more work. =20 only makes is process the
few chunks that are up to 20% full
On Wed, May 7, 2014 at 9:35 AM, Kenny MacDermid
kenny.macder...@gmail.com wrote:
On Tue, May 6, 2014 at 11:22 PM, Liu Bo bo.li@oracle.com wrote:
What does sysrq+w say when the hang happens?
The whole system isn't hung, I may have explained that wrong. The
system will hang if I try to
On Tue, May 06, 2014 at 05:43:24PM +0100, Hugo Mills wrote:
So in my case when I hit that case, I had to use dusage=0 to recover.
Anything above that just didn't work.
I suspect when using more than zero the first chunk it wanted to balance
wasn't empty - and it had nowhere to put it.
On Wed, May 07, 2014 at 04:09:27PM +0200, David Sterba wrote:
On Tue, May 06, 2014 at 05:43:24PM +0100, Hugo Mills wrote:
So in my case when I hit that case, I had to use dusage=0 to recover.
Anything above that just didn't work.
I suspect when using more than zero the first chunk it
On Wed, May 07, 2014 at 03:23:01PM +0100, Hugo Mills wrote:
N=n
F=0
while (N 0) {
balance -dusage=F,limit=N
N -= number of balanced chunks
F++
}
The patch is in branch dev/balance-limit in my git repos.
We can then implement the n-least-full as a synthetic
On Sun, Feb 09, 2014 at 11:45:12PM +, Filipe David Borba Manana wrote:
This is an extension to my previous commit titled:
Btrfs: faster file extent item replace operations
(hash 1acae57b161ef1282f565ef907f72aeed0eb71d9)
Instead of inserting the new file extent item if we deleted
On 05/07/2014 11:21 AM, Liu Bo wrote:
On Sun, Feb 09, 2014 at 11:45:12PM +, Filipe David Borba Manana wrote:
This is an extension to my previous commit titled:
Btrfs: faster file extent item replace operations
(hash 1acae57b161ef1282f565ef907f72aeed0eb71d9)
Instead of inserting the
--
Good day.
Did You Get The Last Email We Sent You?
--
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Add more control to the balance behaviour.
Usage filter may not be finegrained enough and can lead to moving too
many chunks at once. Another example use is in connection with
drange+devid or vrange filters that allow to work with a specific chunk
or even with a chunk on a given device.
The
This started as debugging helper, to watch the effects of converting
between raid levels on multiple devices, but could be useful standalone.
In my case the usage filter was not finegrained enough and led to
converting too many chunks at once. Another example use is in connection
with
Provide the basic information about filesystem through the ioctl:
* b-tree node size (same as leaf size)
* sector size
* expected alignment of CLONE_RANGE and EXTENT_SAME ioctl arguments
Backward compatibility: if the values are 0, kernel does not provide
this information, the applications should
Similar to the FS_INFO updates, export the basic filesystem info through
sysfs: node size, sector size and clone alignment.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/sysfs.c | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff
Hi back,
On Mon, May 05, 2014 at 10:28:13AM -0400, Josef Bacik wrote:
I had way too much email so I just deleted it all, if there was something
you wanted my specific attention on then bounce it back at me and I'll look
at it. Thanks,
it would be really great if you resurrect btrfs-next.
On 05/07/2014 12:38 PM, David Sterba wrote:
Hi back,
On Mon, May 05, 2014 at 10:28:13AM -0400, Josef Bacik wrote:
I had way too much email so I just deleted it all, if there was something
you wanted my specific attention on then bounce it back at me and I'll look
at it. Thanks,
it would be
On 05/07/2014 01:39 PM, Marc MERLIN wrote:
On Wed, May 07, 2014 at 11:35:52AM +, Duncan wrote:
Marc MERLIN posted on Wed, 07 May 2014 01:56:12 -0700 as excerpted:
On Tue, May 06, 2014 at 04:26:48PM +, Duncan wrote:
Marc MERLIN posted on Sun, 04 May 2014 22:04:59 -0700 as excerpted:
On Wed, May 7, 2014 at 4:21 PM, Liu Bo bo.li@oracle.com wrote:
On Sun, Feb 09, 2014 at 11:45:12PM +, Filipe David Borba Manana wrote:
This is an extension to my previous commit titled:
Btrfs: faster file extent item replace operations
(hash
It's unsigned in the structure definition.
Reviewed-by: Mark Fasheh mfas...@suse.de
---
print-tree.c | 12 ++--
qgroup.c | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/print-tree.c b/print-tree.c
index 7263b09..adef94a 100644
--- a/print-tree.c
+++
Hi,
The following 3 patches add support to btrfsck to check the counts
in subvolume quota groups. With these patches a user can run btrfsck against
a volume and if quota is enabled, qgroup data will be checked against the
actual space used on disk. I also added a --qgroup-report option
qgroup-verify.c wants this for walking root refs.
Signed-off-by: Mark Fasheh mfas...@suse.de
---
Makefile | 3 +-
kerncompat.h | 2 +-
ulist.c | 253 +++
ulist.h | 66
4 files changed, 322 insertions(+),
This patch adds functionality (in qgroup-verify.c) to compute bytecounts in
subvolume quota groups. The original groups are read in and stored in memory
so that after we compute our own bytecounts, we can compare them with those
on disk. A print function is provided to do this comparison and show
On Wed, May 07, 2014 at 01:08:06PM +0200, Tomasz Torcz wrote:
On Wed, May 07, 2014 at 06:56:29PM +0800, Liu Bo wrote:
xxHash is an extremely fast non-cryptographic Hash algorithm, working at
speeds
close to RAM limits.[1] And xxhash is 32-bits hash, same as crc32.
Here is the hash
I don't have flink support in my xfsprogs, but it doesn't fail with command not
found or whatever, it fails because I don't have the -T option. So fix
_require_xfs_io_command to check for an invalid option and not run. This way I
get notrun instead of a failure. Thanks,
Signed-off-by: Josef
On Wed, May 7, 2014 at 1:50 PM, Darrick J. Wong darrick.w...@oracle.com wrote:
Just for kicks I (sloppily) benchmarked a few of the kernel's hash
implementations on a Core i5-3320M CPU @3.3GHz:
xxhash: 6.0GB/s
crc32c-intel: 11.5GB/s
crc32c (no hw accel): 1.8GB/s
CRC also usually has the very
On 03/09/2014 11:44 PM, Wang Shilong wrote:
Test flow is to run fsstress after triggering quota rescan.
the ruler is simple, we just remove all files and directories,
sync filesystem and see if qgroup's ref and excl are nodesize.
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
---
v1-v2:
This exercises the various parts of the new qgroup accounting code. We do some
basic stuff and do some things with the shared refs to make sure all that code
works. I had to add a bunch of infrastructure because I needed to be able to
insert items into a fake tree without having to do all the
On Wed, May 7, 2014 at 3:52 AM, Marc MERLIN m...@merlins.org wrote:
On Wed, May 07, 2014 at 09:29:41AM +0100, Hugo Mills wrote:
On Wed, May 07, 2014 at 01:18:40AM -0700, Marc MERLIN wrote:
On Tue, May 06, 2014 at 07:39:12PM +, Duncan wrote:
That appears to be a very good use of either
In a moment of irony, my laptop's boot SSD's btrfs fileysstem crashed
last night with my btrfs talk slides still open on it. It went read only
overnight
but did not crash.
Please tell me ASAP if you need anything off the filesystem before I recover it
since I'm travelling, and need to bring my
On 05/07/2014 07:39 PM, Marc MERLIN wrote:
In a moment of irony, my laptop's boot SSD's btrfs fileysstem crashed
last night with my btrfs talk slides still open on it. It went read only
overnight
but did not crash.
Please tell me ASAP if you need anything off the filesystem before I recover it
On Wed, May 07, 2014 at 08:38:38PM -0400, Chris Mason wrote:
Looks like you're on 3.14, did this have the fixes from my git tree
that went into 3.15-rc?
You're correct, it's running 3.14.0. Considering that it's my main laptop
that I kind of need to work, I avoid rc kernels if possible :)
But
This patch adds an option '--check-data-csum' to verify data csums.
fsck won't check data csums unless users specify this option explictly.
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
---
Documentation/btrfs-check.txt | 2 +
cmds-check.c | 122
On Wed, May 07, 2014 at 05:43:44PM -0700, Marc MERLIN wrote:
A full dd image is not practical, it's 1TB and I have nowhere to put it.
I could do an image if you'd like, and upload it when I have proper
internet (I'm thinking it's likely going to be a 1GB upload)
In the meantime, here is fsck
Original Message
Subject: Re: [PATCH] btrfs-progs: doc: link btrfsck to btrfs-check
From: David Sterba dste...@suse.cz
To: Qu Wenruo quwen...@cn.fujitsu.com
Date: 2014年04月18日 22:48
On Thu, Apr 17, 2014 at 08:47:28AM +0800, Qu Wenruo wrote:
@@ -73,6 +74,7 @@ install:
On Mon, 10 Mar 2014 09:35:13 -0400, Josef Bacik wrote:
On 03/06/2014 12:55 AM, Miao Xie wrote:
Before applying this patch, the task had to reclaim the metadata
space by itself if the metadata space was not enough. And When the
task started the space reclamation, all the other tasks which
Before applying this patch, the task had to reclaim the metadata space
by itself if the metadata space was not enough. And When the task started
the space reclamation, all the other tasks which wanted to reserve the
metadata space were blocked. At some cases, they would be blocked for
a long time,
On Wed, May 07, 2014 at 09:35:06AM -0300, Kenny MacDermid wrote:
On Tue, May 6, 2014 at 11:22 PM, Liu Bo bo.li@oracle.com wrote:
What does sysrq+w say when the hang happens?
The whole system isn't hung, I may have explained that wrong. The
system will hang if I try to shutdown, and
Add '-f' option for btrfs-show-super manpage,
This option implies that sys chunk array and backup roots info
will show up.
Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com
---
Documentation/btrfs-show-super.txt | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
On 05/08/2014 04:58 AM, Josef Bacik wrote:
On 03/09/2014 11:44 PM, Wang Shilong wrote:
Test flow is to run fsstress after triggering quota rescan.
the ruler is simple, we just remove all files and directories,
sync filesystem and see if qgroup's ref and excl are nodesize.
Signed-off-by: Wang
On Wed, May 07, 2014 at 02:33:18PM +0200, David Disseldorp wrote:
With kernel commit 00fdf13a2e9f313a044288aa59d3b8ec29ff904a, the first
clone-range overwrite attempt now fails with EOPNOTSUPP, rather than
tripping a Btrfs BUG_ON().
This test now trips a new Btrfs bug, in which EIO is
On 5/7/14, 3:54 PM, Josef Bacik wrote:
I don't have flink support in my xfsprogs, but it doesn't fail with command
not
found or whatever, it fails because I don't have the -T option. So fix
_require_xfs_io_command to check for an invalid option and not run. This way
I
get notrun instead
Even CONFIG_BTRFS_FS_POSIX_ACL is not defined, the acl still could
been enabled using a mount option, and now fs/btrfs/acl.o is not
built, so the mount options will appear to be supported but will
be silently ignored.
Signed-off-by: Guangliang Zhao lucienc...@gmail.com
---
fs/btrfs/super.c |
64 matches
Mail list logo
