On Thu, May 08, 2014 at 12:11:24PM +0800, Liu Bo wrote:
> 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
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
---
fs/btrfs/super.c |2 ++
1 file changed,
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 i
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 re
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 Sh
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
---
Documentation/btrfs-show-super.txt | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/btrfs-show-super.tx
Add sys chunk array and backup roots info if the new option '-f'
if specified.
This may be useful for debugging sys_chunk related issues.
Signed-off-by: Gui Hecheng
---
btrfs-show-super.c | 138 -
print-tree.c | 2 +-
print-tree.h
On Wed, May 07, 2014 at 09:35:06AM -0300, Kenny MacDermid wrote:
> On Tue, May 6, 2014 at 11:22 PM, Liu Bo 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 the process wil
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 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
Original Message
Subject: Re: [PATCH] btrfs-progs: doc: link btrfsck to btrfs-check
From: David Sterba
To: Qu Wenruo
Date: 2014年04月18日 22:48
On Thu, Apr 17, 2014 at 08:47:28AM +0800, Qu Wenruo wrote:
@@ -73,6 +74,7 @@ install: install-man
install-man: man
$(INSTALL
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
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
---
Documentation/btrfs-check.txt | 2 +
cmds-check.c | 122 --
2 fil
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
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
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 la
On Wed, May 07, 2014 at 04:54:47PM -0400, 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 w
On Wed, May 7, 2014 at 3:52 AM, Marc MERLIN 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 -d raid0
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 har
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
---
v1->v2:
switch into new h
On Wed, May 7, 2014 at 1:50 PM, Darrick J. Wong 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 mild data recovery
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 B
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
qgroup-verify.c wants this for walking root refs.
Signed-off-by: Mark Fasheh
---
Makefile | 3 +-
kerncompat.h | 2 +-
ulist.c | 253 +++
ulist.h | 66
4 files changed, 322 insertions(+), 2 deletions(-)
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 t
It's unsigned in the structure definition.
Reviewed-by: Mark Fasheh
---
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
+++ b/print-tree.c
@@ -884,1
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 that
On Wed, May 7, 2014 at 4:21 PM, 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)
>>
>> In
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 ex
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 r
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. M
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
---
fs/btrfs/sysfs.c | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/s
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 drange+devid
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 limit
--
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
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
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 del
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 -=
> > F++
> > }
> >
> > The patch is in branch dev/balance-limit in my git repos.
> >
> > We can then implement the n-least-full as a synthetic filter
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
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 t
On Wed, May 7, 2014 at 9:35 AM, Kenny MacDermid
wrote:
> On Tue, May 6, 2014 at 11:22 PM, Liu Bo 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 the process will hang if I
On Wed, 7 May 2014 04:30:30 -0700
Marc MERLIN 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 which won't
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):
>>
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.
Signed-
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
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 snapsho
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 s
On Wed, May 07, 2014 at 12:53:11PM +0200, Brendan Hide wrote:
> 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 ch
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
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
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
From: root
Signed-off-by: Liu Bo
---
Makefile |4 +-
crc32c.h |4 +-
disk-io.c |2 +-
hash.h|2 +-
xxhash.c | 448 +
xxhash.h | 171 +++
6 files changed, 626 insertions(+), 5 deletions(-)
This will be used in btrfs, and maybe in others in the future.
Signed-off-by: Liu Bo
---
crypto/Kconfig | 7 +
crypto/Makefile | 1 +
crypto/xxhash.c | 383
include/crypto/xxhash.h | 209 ++
4 f
"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)
"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
Signed-off-by: Liu Bo
---
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
@@ -3153,6 +3153,16
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.
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% f
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
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", an
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 n
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
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 05:16:0
Original Message
Subject: Re: [RFC PATCH 1/2] btrfs: Add missing device check in
dev_info/rm_dev ioctl
From: Anand Jain
To: Qu Wenruo
Date: 2014年05月07日 16:00
Thanks for working on this.
I am running some tests will let you know.
Anand
Thanks for your tests.
I have only
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 [...]
>
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
reque
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
68 matches
Mail list logo
