I have no idea if this is a problem or not so I'm reporting it in case it is.
Non-critical throway test system. Warning occurs with kernel
3.12.0-0.rc3.git0.1.fc21.x86_64
1.
Fedora 20 alpha installation, with boot root home on subvolumes. Autodefrag is
not used by the installer.
The file
On Mon, Sep 23, 2013 at 02:17:19PM +0800, Wang Shilong wrote:
Firstly, we restructure show_qgroups, make it easy to add new features.
And then we add '-p' '-c', '-l',and '-e' options to print the parent
qgroup id, child qgroup id, max referenced size and max exclusive size
of qgroup
On Sat, Sep 28, 2013 at 12:21:51AM +0800, Wang Shilong wrote:
Following this patch the idea is to use lblkid to scan
for the btrfs disks by default which means we don't
use BTRFS_SCAN_PROC any more.
Firstly, i would like to know if we will get any different results between
scanning
Hi David,
On Mon, Sep 23, 2013 at 02:17:19PM +0800, Wang Shilong wrote:
Firstly, we restructure show_qgroups, make it easy to add new features.
And then we add '-p' '-c', '-l',and '-e' options to print the parent
qgroup id, child qgroup id, max referenced size and max exclusive size
of
On Tue, Oct 01, 2013 at 11:37:22AM +0800, Liu Bo wrote:
On Mon, Sep 30, 2013 at 01:02:49PM -0400, Josef Bacik wrote:
On Mon, Sep 30, 2013 at 08:39:57PM +0800, Liu Bo wrote:
The crash[1] is found by xfstests/generic/208 with -o compress,
it's not reproduced everytime, but it does panic.
This patch allows us to garble the generation field of a metadata block. We
will search down to the block, set the bogus generation and write the block back
out. I used this for verifying a transid fix patch for btrfsck. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
Chris Murphy posted on Mon, 30 Sep 2013 23:26:16 -0600 as excerpted:
The other thing, clearly the OP is surprised it's taking anywhere near
this long. Had he known in advance, he probably would have made a
different choice.
I had a longer version that I wrote first, but decided was /too/ long
This is a verification test for the transid recow functionality of btrfsck.
I've also adjusted the test script to spit out which image it's testing so I can
be sure the image was getting tested. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
tests/fsck-tests.sh |
On Mon, Sep 23, 2013 at 03:18:17PM -0400, Frank Holton wrote:
Add an option to defrag all files in a directory recursively.
I had this patch merged but still saw some problems. If there's eg. a
symlink to file on another filesystem, defrag fails with
ERROR: defrag range ioctl not supported in
A user was reporting an issue with bad transid errors on his blocks. The thing
is that btrfs-progs will ignore transid failures for things like restore and
fsck so we can do a best effort to fix a users file system. So fsck can put
together a coherent view of the file system with stale blocks.
On Sun, Sep 29, 2013 at 11:02:29PM +0800, Anand Jain wrote:
this is to avoid duplicate codes, which indeed spans across
most of the search functions that's in there in btrfs-progs.
what you suggest is good, but its better to do that collectively.
Good cleanup idea, added to wiki todo list.
On Sun, Sep 29, 2013 at 11:25:36PM +0800, Anand Jain wrote:
It needs a lot more information about the snapshots if
snapshot's life cycle has to be all auto managed by
scripts _some day_. this patch is a step towards that.
This patch provides the size which would be freed
if the
On Tue, Oct 01, 2013 at 08:25:38PM +0800, Wang Shilong wrote:
* -l sounds less intuitive, I suggest to use -r as for
'referenced', given that there is -e for 'exclusive'.
Yeah, here -l means limited size. Anyway, this is a little obscure.
Maybe -r is better, but it may let user think it
On Sun, Sep 29, 2013 at 11:25:36PM +0800, Anand Jain wrote:
It needs a lot more information about the snapshots if
snapshot's life cycle has to be all auto managed by
scripts _some day_. this patch is a step towards that.
This patch provides the size which would be freed
if the
On Sat, Sep 28, 2013 at 10:51:54AM -0700, Saul Wold wrote:
On 09/28/2013 05:29 AM, Chris Mason wrote:
Ah great news! I want to verify is your git repo for btrfs-progs the main
upstream? I see loads of other patches flying around, but not applied
there.
The patches land in the integration
On Fri, Sep 27, 2013 at 09:45:44AM -0400, Josef Bacik wrote:
On Wed, Sep 18, 2013 at 01:17:55PM +0800, Liu Bo wrote:
btrfs/010 is going to create a fragmented file, however, with autodefrag
this is impossible, so just skip the test when we're with autodefrag.
Signed-off-by: Liu Bo
On Fri, Sep 20, 2013 at 02:13:08PM +0800, Qu Wenruo wrote:
* WQ_MEM_RECLAIM for the scrub thread does not seem right
I think scrub_workers,scrub_wr_completion_workers still need WQ_MEM_RECLAIM.
However scrub_nocow_workers does not need WQ_MEM_RECLAIM flags.
Did you mean this?
If you
On Sat, Sep 28, 2013 at 10:51:54AM -0700, Saul Wold wrote:
On 09/28/2013 05:29 AM, Chris Mason wrote:
Ah great news! I want to verify is your git repo for btrfs-progs the main
upstream? I see loads of other patches flying around, but not applied
there.
The patches land in the integration
In tree-log.c:btrfs_log_inode(), we keep calling btrfs_search_forward()
until it returns a key whose objectid is higher than our inode or until
the key's type is higher than our maximum allowed type.
At the end of the loop, we increment our mininum search key's objectid
and type regardless of our
It is not used for anything.
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
fs/btrfs/ctree.c |1 -
fs/btrfs/ctree.h |1 -
fs/btrfs/ioctl.c | 16 ++--
fs/btrfs/tree-defrag.c |2 +-
fs/btrfs/tree-log.c|9 ++---
Add the -r option to the manpages for btrfs defragment
Signed-off-by: Frank Holton fhol...@gmail.com
---
man/btrfs.8.in |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index b6a7edd..8a0a05d 100644
--- a/man/btrfs.8.in
+++
On Tue, Oct 01, 2013 at 08:38:30AM -0400, Josef Bacik wrote:
No we needed his other addition below which is important, for when the
delalloc
range starts before but still encompasses our page. The other part is not
needed, we should be returning 0 if delalloc_end lands before or on our
The crash[1] is found by xfstests/generic/208 with -o compress,
it's not reproduced everytime, but it does panic.
The bug is quite interesting, it's actually introduced by a recent commit
(573aecafca1cf7a974231b759197a1aebcf39c2a,
Btrfs: actually limit the size of delalloc range).
Btrfs
In tree-log.c:btrfs_log_inode(), we keep calling btrfs_search_forward()
until it returns a key whose objectid is higher than our inode or until
the key's type is higher than our maximum allowed type.
At the end of the loop, we increment our mininum search key's objectid
and type regardless of our
Hi Greg,
On Fri, Sep 20, 2013 at 09:53:02AM -0700, Greg KH wrote:
Thanks for this, I'll queue them up soon.
3.11.3 has been just released and the btrfs fixes are not there nor in
the stable-queue git repo. There's a fix for a crash that affects
a number of users. Please queue the patches or let
On Mon, Sep 30, 2013 at 11:07:20PM +0200, Aastha Mehta wrote:
On 30 September 2013 22:47, Josef Bacik jba...@fusionio.com wrote:
On Mon, Sep 30, 2013 at 10:30:59PM +0200, Aastha Mehta wrote:
On 30 September 2013 22:11, Josef Bacik jba...@fusionio.com wrote:
On Mon, Sep 30, 2013 at
On Tue, Oct 01, 2013 at 07:03:44PM +0200, David Sterba wrote:
Hi Greg,
On Fri, Sep 20, 2013 at 09:53:02AM -0700, Greg KH wrote:
Thanks for this, I'll queue them up soon.
3.11.3 has been just released and the btrfs fixes are not there nor in
the stable-queue git repo. There's a fix for a
On 1 October 2013 19:34, Josef Bacik jba...@fusionio.com wrote:
On Mon, Sep 30, 2013 at 11:07:20PM +0200, Aastha Mehta wrote:
On 30 September 2013 22:47, Josef Bacik jba...@fusionio.com wrote:
On Mon, Sep 30, 2013 at 10:30:59PM +0200, Aastha Mehta wrote:
On 30 September 2013 22:11, Josef
On 1 October 2013 21:42, Aastha Mehta aasth...@gmail.com wrote:
On 1 October 2013 21:40, Aastha Mehta aasth...@gmail.com wrote:
On 1 October 2013 19:34, Josef Bacik jba...@fusionio.com wrote:
On Mon, Sep 30, 2013 at 11:07:20PM +0200, Aastha Mehta wrote:
On 30 September 2013 22:47, Josef Bacik
On 09/28/2013 05:29 AM, Chris Mason wrote:
Quoting Saul Wold (2013-09-19 14:19:34)
Hi there,
I am attempting to build a rootfs image from an existing rootfs
directory tree. I am using the 0.20 @ 194aa4a of Chris's git repo.
The couple problem I saw was that the target image file needed to
Greetings,
I've been using btrfs for bulk-storage purposes for a couple of years now (on
vanilla linux-stable kernels on a few machines). I recently set up a new
filesystem and have been copying data to it, when I had an unrelated kernel
lockup. As expected, after rebooting btrfsck reported
Hi, Chris,
Chris Murphy li...@colorremedies.com wrote:
On Oct 1, 2013, at 3:12 PM, Charles Cazabon
charlesc-lists-bt...@pyropus.ca wrote:
Running btrfsck with the --repair option, however, does not appear to fix
these [checksum verify] problems. I'll attach the complete output of
On Oct 1, 2013, at 5:46 PM, Charles Cazabon charlesc-lists-bt...@pyropus.ca
wrote:
# btrfs fi df /media/bigbackup/
Data: total=4.53TB, used=4.22TB
System, DUP: total=8.00MB, used=508.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=18.00GB, used=17.13GB
Metadata:
Sorry,
I misunderstood and thought you had already queued them. Both are fine with me.
-chris
From: Greg KH [gre...@linuxfoundation.org]
Sent: Tuesday, October 01, 2013 1:49 PM
To: dste...@suse.cz; sta...@vger.kernel.org; Josef Bacik; Chris Mason;
Hi Saul,
The patch ended up a little bigger than I expected because it is sharing
infrastructure with btfs-convert. Travel added a little more delay, but I'm
almost there.
-chris
From: Saul Wold [s...@linux.intel.com]
Sent: Tuesday, October 01, 2013
On Tue, 1 Oct 2013 16:50:50 +0200, David Sterba wrote:
On Fri, Sep 20, 2013 at 02:13:08PM +0800, Qu Wenruo wrote:
* WQ_MEM_RECLAIM for the scrub thread does not seem right
I think scrub_workers,scrub_wr_completion_workers still need WQ_MEM_RECLAIM.
However scrub_nocow_workers does not need
Chris Murphy li...@colorremedies.com wrote:
On Oct 1, 2013, at 5:46 PM, Charles Cazabon wrote:
# btrfs fi df /media/bigbackup/
Data: total=4.53TB, used=4.22TB
System, DUP: total=8.00MB, used=508.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=18.00GB, used=17.13GB
On Oct 1, 2013, at 9:13 PM, Charles Cazabon charlesc-lists-bt...@pyropus.ca
wrote:
Ah, I'm not looking to repair the files -- I can recopy the files easily
enough, and rsync will pick up any files whose contents have been corrupted.
I'd like to get the filesystem fixed, though. i.e., even
On Wed, Oct 02, 2013 at 01:15:19AM +, Chris Mason wrote:
Sorry,
I misunderstood and thought you had already queued them. Both are fine with
me.
Ok, no worries, I'll pick them up in the next few days and add them to
the next stable releases.
thanks,
greg k-h
--
To unsubscribe from
39 matches
Mail list logo
