2011-10-28, 10:25(+08), Li Zefan:
[...]
# df . -h
FilesystemSize Used Avail Use% Mounted on
/home/lizf/tmp/a 2.0G 409M 1.4G 23% /mnt
OK, why are we not gaining space after compression though?
And I was not suprised, as there's a regression.
With this fix:
2011-10-28, 07:57(+07), Fajar A. Nugraha:
[...]
Already got 'em. Everything that tries to even think about modifying stuff
(btrfs-zero-log, btrfsck, and btrfs-debug-tree) all dump core:
Your last resort (for now, anyway) might be using restore from
Josef's btrfs-progs:
Hi everyone,
I've pulled in Hugo's integration tree, minus the features that were not
yet in the kernel. This also has a few small commits that I had queued
up outside of the fsck work.
Hugo, many thanks for keeping up the integration tree! Taking out the
features not in the kernel
Btrfs uses anon bdevs, this is not needed.
Signed-off-by: Ilya Dryomov idryo...@gmail.com
---
fs/btrfs/volumes.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index f2a4cc7..afd6a1e 100644
--- a/fs/btrfs/volumes.c
+++
Newly created file on btrfs inherits inode flags from parent directory,
so new inode created in append-only directory has S_APPEND flag set,
may_open() called by do_last() checks that flag then returns -EPERM,
but at that time the new inode is already created.
This can be reproduced by:
#
Hi Johannes,
I tested this patchset over the IO-less dirty throttling one.
The below numbers show that
//improvements
1) write bandwidth increased by 1% in general
2) greatly reduced nr_vmscan_immediate_reclaim
//regression
3) much increased cpu %user and %system for btrfs
Thanks,
Fengguang
[restore CC list]
I'm trying to understand where the performance gain comes from.
I noticed that in all cases, before/after patchset, nr_vmscan_write are all
zero.
nr_vmscan_immediate_reclaim is significantly reduced though:
That's a good thing, it means we burn less CPU time on
Hello!
Today I downgraded from Ubuntu's APT repo oneiric-proposed (which
brings some kernel 3.0.0-13) back to the standard repo oneiric.
Now I'm not able to mount my btrfs / and /home (both on the same
partition) anymore:
device fsid SOME-UUID devid 1 transid 84229 /dev/dm-0
parent
On Fri, Oct 28, 2011 at 08:36:28PM +, em...@joachim-neu.de wrote:
Today I downgraded from Ubuntu's APT repo oneiric-proposed (which
brings some kernel 3.0.0-13) back to the standard repo oneiric.
It's odd that switching from one 3.0.0 to another would cause
something bad to happen. Did
On Fri, 28 Oct 2011 22:09:47 +0100, Hugo Mills h...@carfax.org.uk
wrote:
On Fri, Oct 28, 2011 at 08:36:28PM +, em...@joachim-neu.de wrote:
Today I downgraded from Ubuntu's APT repo oneiric-proposed (which
brings some kernel 3.0.0-13) back to the standard repo oneiric.
It's odd that
On Oct 28, 2011, Marcel Lohmann mar...@malowa.de wrote:
I would really appreciate if you could send me the patches.
Here are the patches I mentioned on IRC. I've sent two of them to Josef
for him to push upstream, but I'm not sure he posted them here for I'm
not on the list (yet?). The other
On Sat, Oct 29, 2011 at 02:35:16AM -0200, Alexandre Oliva wrote:
On Oct 28, 2011, Marcel Lohmann mar...@malowa.de wrote:
I would really appreciate if you could send me the patches.
Here are the patches I mentioned on IRC. I've sent two of them to Josef
for him to push upstream, but I'm
12 matches
Mail list logo
