I'd guess normal df (not btrfs filesystem df) and doing the math in his
head will be the simplest for him, as it is for me.
But it's worth noting that normal df with math in your head isn't
/always/ going to be the answer, as things start getting rather more
complex as soon as different sized
On 05/30/2013 02:55 PM, Stefan Behrens wrote:
On Thu, 30 May 2013 08:32:35 -0400, Josef Bacik wrote:
On Thu, May 30, 2013 at 05:17:06AM -0600, Papp Tamas wrote:
hi All,
I'm new on the list.
System:
Distributor ID: Ubuntu
Description:Ubuntu 13.04
Release:13.04
Codename:
On Mon, Jun 03, 2013 at 01:56:10PM +0200, Papp Tamas wrote:
On 05/30/2013 02:55 PM, Stefan Behrens wrote:
On Thu, 30 May 2013 08:32:35 -0400, Josef Bacik wrote:
On Thu, May 30, 2013 at 05:17:06AM -0600, Papp Tamas wrote:
hi All,
I'm new on the list.
System:
Distributor ID:Ubuntu
Hi,
commit 46de1a6ec3dbb0db203baa6c46cb64ba9b000ea2 changed the
parameters of btrfs_read_and_process_send_stream(). This breaks
snapper compilation so I wonder whether we can include version
defines usable for the C preprocessor. Surely it won't help in
this case anymore but might in the
On 06/02/2013 07:58 PM, Liu Bo wrote:
On Sun, Jun 02, 2013 at 07:11:10PM -0700, George Mitchell wrote:
On 06/02/2013 06:28 PM, Liu Bo wrote:
On Sun, Jun 02, 2013 at 07:40:52AM -0700, George Mitchell wrote:
I am seeing massive journal corruptions that seem to be unique to
btrfs and I am
I have seen a lot of boilerplate code that either follows the pattern of
while (!list_empty(head)) {
pos = list_entry(head-next, struct foo, list);
list_del(pos-list);
...
}
or some variant thereof.
With this patch in, people can use
A purely janitorial patchset. A fairly common pattern is to take a
list, remove every object from it and do something with this object -
usually kfree() some variant. A stupid grep identified roughly 300
instances, with many more hidden behind more complicated patterns to
achieve the same end
Signed-off-by: Joern Engel jo...@logfs.org
---
fs/btrfs/backref.c | 15 +++
fs/btrfs/compression.c |4 +---
fs/btrfs/disk-io.c |6 +-
fs/btrfs/extent-tree.c | 17 +++--
fs/btrfs/extent_io.c|8 ++--
fs/btrfs/inode.c| 16
There is a problem where if we find a backref extent record first that doesn't
match a extent item we will delete some of the duplicates but not others. In
order to deal with this we need to make sure we only pay attention to duplicates
that actually have duplicate extent items. If a extent_rec
On Mon, 3 June 2013 13:28:03 -0400, Joern Engel wrote:
Drawback is that object size is growing. I think an ideal compiler
should be able to optimize all the overhead away, but 4.7 just isn't
there yet. Or maybe I just messed up - patches are only
compile-tested after all. Comments/ideas
When testing a corrupted fs I noticed I was getting sleep while atomic errors
when the transaction aborted. This is because btrfs_pin_extent may need to
allocate memory and we are calling this under the spin lock. Fix this by moving
it out and doing the pin after dropping the spin lock but
There are some error cases that we don't do an iput() on our inode, fix this.
Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/inode.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index b11a95e..d37bccf 100644
On Mon, 3 June 2013 15:36:47 -0400, Jörn Engel wrote:
On Mon, 3 June 2013 13:49:30 -0700, Christoph Hellwig wrote:
I can't say I like the structure.
A list_pop that removes and entry from the head or returns NULL if the
list is empty would lead to nice while loops that are obviously
I can't say I like the structure.
A list_pop that removes and entry from the head or returns NULL if the
list is empty would lead to nice while loops that are obviously
readable instead.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to
When we cross into a different subvol when doing a lookup we will run the orhpan
cleanup. If this fails however we do not drop the ref to the inode we were
looking up before we return an error, which leads to busy inodes on umount.
Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
On Sun, Jun 2, 2013 at 9:05 PM, John Haller john.h.hal...@gmail.com wrote:
Hi,
I added a new drive to an existing RAID 0 array. Every
attempt to rebalance the array fails:
# btrfs filesystem balance /share/bd8
btrfs csum failed ino 365 off 221745152 csum 3391451932 private 3121065028
btrfs
Balance will create reloc_root for each fs root, and it's going to
record last_snapshot to filter shared blocks. The side effect of
setting last_snapshot is to break nocow attributes of files.
So it turns out that checking last_snapshot does not always ensure that
a node/leaf/file_extent is
Tim Eggleston posted on Mon, 03 Jun 2013 09:02:26 +0100 as excerpted:
I'd guess normal df (not btrfs filesystem df) and doing the math in his
head will be the simplest for him, as it is for me.
But it's worth noting that normal df with math in your head isn't
/always/ going to be the
18 matches
Mail list logo
