On Thu, 07 Jun 2012 21:38:25 +0200, Goffredo Baroncelli wrote:
Hi Stefan,
On 05/25/2012 04:07 PM, Stefan Behrens wrote:
This is a preparation step to add support for device stats. The definition
of the function open_file_or_dir() is moved from common.c to utils.c in
order to be able to
Hi all,
I have two multi-disk btrfs filesystems on a Arch linux 3.4.0 system.
After a power failure, both filesystems refuse to mount
[ 10.402284] Btrfs loaded
[ 10.402714] device fsid 1e7c18a4-02d6-44b1-8eaf-c01378009cd3 devid 4
transid 65282 /dev/sdc
[ 10.403108] btrfs: force zlib
On Παρασκευή, 8 Ιούνιος 2012 11:28:39 πμ, Tomasz Torcz wrote:
On Fri, Jun 08, 2012 at 11:26:21AM +0300, Konstantinos Skarlatos wrote:
Hi all,
I have two multi-disk btrfs filesystems on a Arch linux 3.4.0
system. After a power failure, both filesystems refuse to mount
Multi-device
On Fri, Jun 08, 2012 at 11:26:21AM +0300, Konstantinos Skarlatos wrote:
Hi all,
I have two multi-disk btrfs filesystems on a Arch linux 3.4.0
system. After a power failure, both filesystems refuse to mount
Multi-device filesystem had to be first fully discovered by
btrfs device scan. It is
On Thu, Jun 07, 2012 at 09:58:44PM +0200, Catalin Iacob wrote:
I just booted into a current git kernel and got 6 of these in about
1h30min of usage
Yeah sorry! I've been working on this all week, I've just about got it nailed
down, go back to 3.4 and you'll be fine for now. Thanks,
Josef
Remove btrfsctl, btrfs-show and btrfs-vol from all target of Makefile.
Signed-off-by: Stefan Behrens sbehr...@giantdisaster.de
---
Makefile |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index aaf1381..79e7a56 100644
--- a/Makefile
+++ b/Makefile
@@
Hi all
the aim of this patch is to add the command btrfs filesystem info to
show some filesystem information. Example:
$ sudo btrfs-progs/btrfs filesystem info /mnt/test
Path: /mnt/test
Max ID: 4
UUID: 1c7e4ba6-aebc-4b39-90ef-c61315fb74d1
Num devices: 3
Dev ID: 2
UUID:
Add btrfs filesystem info command, which is capable to show some
btrfs filesystem information.
---
cmds-filesystem.c | 59 +
1 file changed, 59 insertions(+)
diff --git a/cmds-filesystem.c b/cmds-filesystem.c
index 1f53d1c..9acc715 100644
---
This patch is ispired by a Stefan Behrens one.
---
Makefile |8 +++
cmds-scrub.c | 72 ++
utils.c | 68 ++
utils.h |4
4 files changed, 78 insertions(+),
Update the man page to document the btrfs filesystem info path
command.
---
man/btrfs.8.in |8
1 file changed, 8 insertions(+)
diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index be478e0..6d96bf7 100644
--- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -25,6 +25,8 @@ btrfs \- control a
What kind of info does it give? This is really unhelpful in a man
page, it just tells the obvious.
On Fri, Jun 8, 2012 at 3:12 PM, Goffredo Baroncelli kreij...@inwind.it wrote:
Update the man page to document the btrfs filesystem info path
command.
---
man/btrfs.8.in | 8
1
A user reported lots of problems using compression on the new code and it
turns out part of the problem was that igrab() was failing when we added a
new ordered extent. This is because when writing out an inode under
compression we immediately return without actually doing anything to the
pages,
I removed this in an earlier commit and I was wrong. Because compression
can return from filemap_fdatawrite() without having actually set any of it's
pages as writeback() it can make filemap_fdatawait() do essentially nothing,
and then we won't find any ordered extents because they may not have
On 06/08/2012 09:24 PM, Matthew Hawn wrote:
I just converted my root filesystem to btrfs with btrfs-convert. However,
since I am running Ubuntu, I would like to have the same subvolume structure
as a default install,. How do I move the top-level subvolume (where all my
files currently are)
Hello,
Before the upgrade (on 3.2.18):
Metadata, DUP: total=9.38GB, used=5.94GB
After the FS has been mounted once with 3.4.1:
Data: total=3.44TB, used=2.67TB
System, DUP: total=8.00MB, used=412.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=84.38GB, used=5.94GB
Where did my 75 GB
From: Kirill A. Shutemov kirill.shute...@linux.intel.com
Sorry for resend. Original mail had too long cc list.
There's no reason to call rcu_barrier() on every deactivate_locked_super().
We only need to make sure that all delayed rcu free inodes are flushed
before we destroy related cache.
On Fri, Jun 08, 2012 at 02:43:58PM -0700, Linus Torvalds wrote:
On Fri, Jun 8, 2012 at 2:28 PM, Kirill A. Shutemov
kirill.shute...@linux.intel.com wrote:
From: Kirill A. Shutemov kirill.shute...@linux.intel.com
There's no reason to call rcu_barrier() on every deactivate_locked_super().
On Sat, 9 Jun 2012 00:41:03 +0300
Kirill A. Shutemov kirill.shute...@linux.intel.com wrote:
There's no reason to call rcu_barrier() on every deactivate_locked_super().
We only need to make sure that all delayed rcu free inodes are flushed
before we destroy related cache.
Removing
On Fri, Jun 8, 2012 at 3:00 PM, Kirill A. Shutemov
kirill.shute...@linux.intel.com wrote:
IIUC, moving rcu_barrier() up should help, but I can't say that I fully
understand SLAB_DESTROY_BY_RCU semantics.
.. hmm. I think you may be right. Even if we do move it up, we
probably shouldn't use it.
On Fri, Jun 08, 2012 at 03:02:53PM -0700, Andrew Morton wrote:
On Sat, 9 Jun 2012 00:41:03 +0300
Kirill A. Shutemov kirill.shute...@linux.intel.com wrote:
There's no reason to call rcu_barrier() on every deactivate_locked_super().
We only need to make sure that all delayed rcu free inodes
On Sat, Jun 09, 2012 at 01:14:46AM +0300, Kirill A. Shutemov wrote:
The implementation would be less unpleasant if we could do the
rcu_barrier() in kmem_cache_destroy(). I can't see a way of doing that
without adding a dedicated slab flag, which would require editing all
the filesystems
On Fri, Jun 08, 2012 at 03:06:20PM -0700, Linus Torvalds wrote:
.. hmm. I think you may be right. Even if we do move it up, we
probably shouldn't use it.
We don't even want SLAB_DESTROY_BY_RCU, since we do the delayed RCU
free for other reasons anyway, so it would duplicate the RCU delaying
On Sat, 9 Jun 2012 01:14:46 +0300
Kirill A. Shutemov kirill.shute...@linux.intel.com wrote:
On Fri, Jun 08, 2012 at 03:02:53PM -0700, Andrew Morton wrote:
On Sat, 9 Jun 2012 00:41:03 +0300
Kirill A. Shutemov kirill.shute...@linux.intel.com wrote:
There's no reason to call
On Fri, Jun 08, 2012 at 03:25:50PM -0700, Andrew Morton wrote:
A neater implementation might be to add a kmem_cache* argument to
unregister_filesystem(). If that is non-NULL, unregister_filesystem()
does the rcu_barrier() and destroys the cache. That way we get to
delete (rather than add) a
On Fri, Jun 8, 2012 at 3:23 PM, Al Viro v...@zeniv.linux.org.uk wrote:
Note that module unload is *not* a hot path - not on any even remotely sane
use.
Actually, I think we've had distributions that basically did a load
pretty much everything, and let God sort it out approach to modules.
I
On Fri, Jun 08, 2012 at 03:25:50PM -0700, Andrew Morton wrote:
On Sat, 9 Jun 2012 01:14:46 +0300
Kirill A. Shutemov kirill.shute...@linux.intel.com wrote:
On Fri, Jun 08, 2012 at 03:02:53PM -0700, Andrew Morton wrote:
On Sat, 9 Jun 2012 00:41:03 +0300
Kirill A. Shutemov
On Sat, 9 Jun 2012 02:31:27 +0300
Kirill A. Shutemov kirill.shute...@linux.intel.com wrote:
On Fri, Jun 08, 2012 at 03:31:20PM -0700, Andrew Morton wrote:
On Fri, 8 Jun 2012 23:27:34 +0100
Al Viro v...@zeniv.linux.org.uk wrote:
On Fri, Jun 08, 2012 at 03:25:50PM -0700, Andrew Morton
On Fri, Jun 8, 2012 at 4:37 PM, Andrew Morton a...@linux-foundation.org wrote:
So how about open-coding the rcu_barrier() in btrfs and gfs2 for the
non-inode caches (which is the appropriate place), and hand the inode
cache over to the vfs for treatment (which is the appropriate place).
The
On Fri, 8 Jun 2012 16:46:47 -0700 Linus Torvalds
torva...@linux-foundation.org wrote:
Of course, if you just mean having a VFS wrapper that does
static void vfs_inode_kmem_cache_destroy(struct kmem_cache *cachep)
{
rcu_barrier();
kmem_cache_destroy(cachep);
}
On 06/08/2012 06:42 AM, Lennert Buytenhek wrote:
(please CC on replies, I'm not subscribed to the list)
Hi!
This fails:
# mkfs.btrfs /dev/sd[bcde]
# mount /dev/sdb /mnt/x
# btrfs device delete /dev/sdb /mnt/x
# btrfs device add /dev/sdb /mnt/x
/dev/sdb
30 matches
Mail list logo
