Can anyone please comment on below?
On Thu, Jan 31, 2013 at 3:03 PM, Alex Lyakas
alex.bt...@zadarastorage.com wrote:
Hi,
I want to check if any of the below issues are worth/should be fixed:
# btrfs_ioctl_snap_destroy() does not commit a transaction. As a
result, user can ask to delete a
Hi Jan, Arne,
I see this code in create_snapshot:
if (inherit) {
pending_snapshot-inherit = *inherit;
*inherit = NULL;/* take responsibility to free it */
}
So, first thing I think it should be:
if (*inherit)
because in
Hi Alex,
On 02/06/13 12:18, Alex Lyakas wrote:
Hi Jan, Arne,
I see this code in create_snapshot:
if (inherit) {
pending_snapshot-inherit = *inherit;
*inherit = NULL;/* take responsibility to free it */
}
So, first thing I think it should
On Wed, Feb 6, 2013 at 4:45 AM, Josef Bacik jba...@fusionio.com wrote:
Ok so I think we've fixed this already, can you build btrfs-next and try
mounting with that and see if it fixes the problem? Thanks,
Hi, Josef,
Is there any btrfs git compatible with kernel 3.7 and absorbs this
fix? So I
On Feb 5, 2013, at 8:11 PM, Liu Bo bo.li@oracle.com wrote:
On Tue, Feb 05, 2013 at 03:14:05PM -0800, Zach Brown wrote:
+struct btrfs_inode *b_inode = BTRFS_I(inode);
+struct btrfs_fs_info *fs_info = b_inode-root-fs_info;
if (atomic_add_unless(inode-i_count, -1, 1))
On 02/05/2013 07:49 PM, Zach Brown wrote:
Hi gang,
Eric and I went through the warnings that a Coverity scan raised against
the reasonably recent btrfs-progs that's in Fedora. We tried to tackle
the lowest hanging fruit: these are the most obvious and least risky
fixes.
If you ran your tests
On Fri, Feb 01, 2013 at 06:41:11PM +0100, David Sterba wrote:
I'm going to do some more testing of the previous integration branch and
send a pull request as of 20130126.
I didn't have that much time for testing as I wanted, at least did
another review round of the pending patchset. Please pull
On 2/6/13 8:27 AM, Gene Czarcinski wrote:
On 02/05/2013 07:49 PM, Zach Brown wrote:
Hi gang,
Eric and I went through the warnings that a Coverity scan raised
against the reasonably recent btrfs-progs that's in Fedora. We
tried to tackle the lowest hanging fruit: these are the most
obvious
On Thu, Jan 31, 2013 at 06:03:06AM -0700, Alex Lyakas wrote:
Hi,
I want to check if any of the below issues are worth/should be fixed:
# btrfs_ioctl_snap_destroy() does not commit a transaction. As a
result, user can ask to delete a subvol, he receives ok back. Even
if user does btrfs sub
On Wed, Feb 06, 2013 at 06:03:14AM -0700, Marguerite Su wrote:
On Wed, Feb 6, 2013 at 4:45 AM, Josef Bacik jba...@fusionio.com wrote:
Ok so I think we've fixed this already, can you build btrfs-next and try
mounting with that and see if it fixes the problem? Thanks,
Hi, Josef,
Is there
On 2/5/13 8:08 PM, Liu Bo wrote:
On Tue, Feb 05, 2013 at 03:14:05PM -0800, Zach Brown wrote:
+ struct btrfs_inode *b_inode = BTRFS_I(inode);
+ struct btrfs_fs_info *fs_info = b_inode-root-fs_info;
if (atomic_add_unless(inode-i_count, -1, 1))
return;
- delayed =
On Wed, Feb 06, 2013 at 09:53:05AM -0600, Eric Sandeen wrote:
On 2/5/13 8:08 PM, Liu Bo wrote:
On Tue, Feb 05, 2013 at 03:14:05PM -0800, Zach Brown wrote:
+ struct btrfs_inode *b_inode = BTRFS_I(inode);
+ struct btrfs_fs_info *fs_info = b_inode-root-fs_info;
if
Provide for modification of the limit of compressed extent size
utilizing mount-time configuration settings.
The size of compressed extents was limited to 128K, which
leads to fragmentation of the extents (although the extents
themselves may still be located contiguously). This limit is
put in
On Tue, Feb 05, 2013 at 05:49:07PM -0700, Zach Brown wrote:
Hi gang,
Eric and I went through the warnings that a Coverity scan raised against
the reasonably recent btrfs-progs that's in Fedora. We tried to tackle
the lowest hanging fruit: these are the most obvious and least risky
fixes.
Awesome, thanks Zach and Eric. I've got this rebased on top of Dave's
integration pull from today, and I'm doing a bunch of tests.
Great, thanks for the pull. We're happy to help!
- z
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to
+ unsigned compressed_extent_size;
It kind of jumps out that this mentions neither that it's the max nor
that it's in KB. How about max_compressed_extent_kb?
+ fs_info-compressed_extent_size = 128;
I'd put a DEFAULT_MAX_EXTENTS up by the MAX_ definition instead of using
a raw 128
People have been complaining about random ENOSPC errors that will clear up
after a umount or just a given amount of time. Chris was able to reproduce
this with stress.sh and lots of processes and so was I. Basically the
overcommit stuff would really let us get out of hand, in my tests I saw up
I noticed we would deadlock if we aborted a transaction while doing
compressed io. This is because we don't unlock our pages if something goes
horribly wrong. To fix this we need to make sure that we call
extent_clear_unlock_delalloc in order to unlock all the pages. If we have
to cow in the
On Mon, Feb 04, 2013 at 10:57:57AM -0500, Gene Czarcinski wrote:
From: Eric Sandeen sand...@redhat.com
print more informative error when we fail to open a device
If open() fails, we should let the user know why it failed.
Thanks, added to next integration queue.
--
To unsubscribe from this
Hi,
my btrfs hangs when doing a balance operation.
I'm using a 3.7.1 kernel from opensuse: linux-opzz 3.7.1-2.10-m4 #11 SMP
PREEMPT Fri Jan 11 18:04:04 CET 2013 x86_64 x86_64 x86_64 GNU/Linux
and Btrfs v0.19+
I did a scrub which completed without errors. Then I tried btrfs filesystem
balance /
On Mon, Feb 04, 2013 at 11:26:23AM -0600, Eric Sandeen wrote:
fd53de4d Drop bit-radix.[ch] files
removed the files from the Makefile, but not the files themselves.
Added to next integration.
david
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message
On Wed, Feb 06, 2013 at 11:12:14PM +0100, Michael Schneider wrote:
Hi,
my btrfs hangs when doing a balance operation.
I'm using a 3.7.1 kernel from opensuse: linux-opzz 3.7.1-2.10-m4 #11 SMP
PREEMPT Fri Jan 11 18:04:04 CET 2013 x86_64 x86_64 x86_64 GNU/Linux
and Btrfs v0.19+
I did a
# btrfs fi show
failed to read /dev/sr0
Label: 'bootssd' uuid: ac89584c-c757-488e-8a2a-5ee5a5484dde
Total devices 1 FS bytes used 34.98GB
devid1 size 56.00GB used 41.07GB path /dev/dm-1
Btrfs v0.19+
# btrfs fi df /
Data: total=35.00GB, used=33.34GB
System, DUP:
On Wed, Feb 6, 2013 at 12:46 PM, Zach Brown z...@redhat.com wrote:
+ unsigned compressed_extent_size;
It kind of jumps out that this mentions neither that it's the max nor
that it's in KB. How about max_compressed_extent_kb?
+ fs_info-compressed_extent_size = 128;
I'd put a
On Tue, Jan 29, 2013 at 02:41:08PM -0600, Eric Sandeen wrote:
The manpage for the -r option simply says that
it will copy the path specified to -r into the newly
made filesystem.
There's not a lot of reason to treat that option as differently
as it is now - today it ignores discard, fs
Hi Linus,
Please pull my for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
We've got corner cases for updating i_size that ceph was hitting, error
handling for quotas when we run out of space, a very subtle snapshot
deletion race, a crash while
[ sorry, my lbdb seems to really like linux-ker...@vger.kerrnel.org,
fixed for real this time ]
Hi Linus,
Please pull my for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
We've got corner cases for updating i_size that ceph was hitting, error
On wed, 06 Feb 2013 13:14:23 +0100, Arne Jansen wrote:
Hi Alex,
On 02/06/13 12:18, Alex Lyakas wrote:
Hi Jan, Arne,
I see this code in create_snapshot:
if (inherit) {
pending_snapshot-inherit = *inherit;
*inherit = NULL;/* take responsibility to
open_ctree() need read the metadata to initialize the global information
of btrfs. But it may fail after it submit some bio, and then it will jump
to the error path. Unfortunately, it doesn't check if there are some bios
in flight, and just stop all the worker threads. As a result, when the
The argument inherit of btrfs_ioctl_snap_create_transid() was assigned
to NULL during we created the snapshots, so we didn't free it though we
called kfree() in the caller.
But since we are sure the snapshot creation is done after the function -
btrfs_ioctl_snap_create_transid() - completes, it
30 matches
Mail list logo
