Lucas de Vries: > I tried to compile something in my aufs directory (I've tried it with > multiple applications, so it's not something specific to that), and > during the configure stage it just dies with: > > ls: cannot access .: Stale NFS file handle
I tried btrfs.
As I expected, the aufs XINO files don't work on btrfs due to its
internal i_blocks. It is OK. When aufs detects that the first writable
branch fs cannot handle XINO files, it will try /tmp as next candidate.
Here is a patch attached for you to support btrfs branch.
But I found some weird behaviours on btrfs, just for your information.
- sparse file may not be supported.
- df -i (the number of inodes) always shows 0.
- repeated ln(1) retuns an error "Too many links", but succeeds after a
short pause. You may reproduce this by this simple script.
#!/bin/sh
l10="0123456789"
l100="${l10}${l10}${l10}${l10}${l10}${l10}${l10}${l10}${l10}${l10}"
> a
o=1000
n=$o
while [ $n -gt 0 ]
do
ln a $l100$n
n=$((${n}-1))
done
- After making btrfs full (by dd if=/dev/zero of=<btrfs>/file, and it
returns "No space left on device" expectedly), df shows many space.
It means that aufs mfs (and its variants) will not work correctly.
But I wonder btrfs has some nice features as garbage collection since
what I used /dev/zero.
- racer.sh test (a fs heavy i/o test kit, you can google and find it)
didn't pass even I tried without aufs. btrfs potentially deadlocks.
=========================================================
[ INFO: possible irq lock inversion dependency detected ]
2.6.32.7aufsD #664
---------------------------------------------------------
file_rename.sh/21624 just changed the state of lock:
(&fs_info->trans_mutex){+.+.-.}, at: [<ffffffffa013af43>]
start_transaction+0x43/0x190 [btrfs]
but this lock took another, RECLAIM_FS-READ-unsafe lock in the past:
(&found->groups_sem){++++.+}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
3 locks held by file_rename.sh/21624:
#0: (&mm->mmap_sem){++++++}, at: [<ffffffff81450911>]
do_page_fault+0x301/0x5c0
#1: (shrinker_rwsem){++++..}, at: [<ffffffff810d7212>] shrink_slab+0x32/0x200
#2: (&type->s_umount_key#37){++++++}, at: [<ffffffff8111f920>]
shrink_dcache_memory+0x120/0x1e0
the shortest dependencies between 2nd lock and 1st lock:
-> (&found->groups_sem){++++.+} ops: 0 {
HARDIRQ-ON-W at:
[<ffffffff81087f05>] __lock_acquire+0x6e5/0x1600
[<ffffffff81088f30>] lock_acquire+0x110/0x150
[<ffffffff8144bdaf>] down_write+0x3f/0x50
[<ffffffffa012c261>]
btrfs_read_block_groups+0x471/0x600 [btrfs]
[<ffffffffa01397b3>] open_ctree+0x1483/0x1800
[btrfs]
::: <snip> :::
stack backtrace:
Pid: 21624, comm: file_rename.sh Not tainted 2.6.32.7aufsD #664
Call Trace:
[<ffffffff8108637c>] print_irq_inversion_bug+0x14c/0x170
[<ffffffff81083790>] ? usage_match+0x0/0x20
[<ffffffff810865b0>] ? check_usage_forwards+0x0/0x110
[<ffffffff81086646>] check_usage_forwards+0x96/0x110
[<ffffffff81087021>] mark_lock+0x2d1/0x410
[<ffffffff81087ca9>] __lock_acquire+0x489/0x1600
[<ffffffff81013394>] ? restore_args+0x0/0x30
[<ffffffff810874ed>] ? trace_hardirqs_on_caller+0x14d/0x1a0
[<ffffffff8144cabe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff81088f30>] lock_acquire+0x110/0x150
[<ffffffffa013af43>] ? start_transaction+0x43/0x190 [btrfs]
[<ffffffff8144b3c9>] __mutex_lock_common+0x59/0x620
[<ffffffffa013af43>] ? start_transaction+0x43/0x190 [btrfs]
[<ffffffffa013af43>] ? start_transaction+0x43/0x190 [btrfs]
[<ffffffffa013af2b>] ? start_transaction+0x2b/0x190 [btrfs]
[<ffffffff8144ba6c>] mutex_lock_nested+0x3c/0x50
[<ffffffffa0143bd0>] ? btrfs_delete_inode+0x0/0x130 [btrfs]
[<ffffffffa013af43>] start_transaction+0x43/0x190 [btrfs]
[<ffffffffa0143bd0>] ? btrfs_delete_inode+0x0/0x130 [btrfs]
[<ffffffffa013b0ae>] btrfs_join_transaction+0xe/0x10 [btrfs]
[<ffffffffa0143c7f>] btrfs_delete_inode+0xaf/0x130 [btrfs]
[<ffffffffa0143bd0>] ? btrfs_delete_inode+0x0/0x130 [btrfs]
[<ffffffff81123666>] generic_delete_inode+0xc6/0x190
[<ffffffff81227f88>] ? _atomic_dec_and_lock+0x98/0xc0
[<ffffffff8112378d>] generic_drop_inode+0x5d/0x80
[<ffffffffa013c161>] btrfs_drop_inode+0x21/0x40 [btrfs]
[<ffffffff81122668>] iput+0x78/0x80
[<ffffffff8111f2d8>] dentry_iput+0x98/0x110
[<ffffffff8111f46e>] d_kill+0x2e/0x60
[<ffffffff8111f76d>] __shrink_dcache_sb+0x2cd/0x360
[<ffffffff8111f95b>] shrink_dcache_memory+0x15b/0x1e0
[<ffffffff810d7382>] shrink_slab+0x1a2/0x200
[<ffffffff810d9b6e>] try_to_free_pages+0x28e/0x3d0
[<ffffffff810d6550>] ? isolate_pages_global+0x0/0x280
[<ffffffff810d151a>] __alloc_pages_nodemask+0x59a/0x9c0
[<ffffffff810ea96b>] do_wp_page+0x59b/0x900
[<ffffffff8123779c>] ? _raw_spin_lock+0xac/0x1b0
[<ffffffff810eba4c>] handle_mm_fault+0x84c/0x9d0
[<ffffffff81450911>] ? do_page_fault+0x301/0x5c0
[<ffffffff81450ad7>] do_page_fault+0x4c7/0x5c0
[<ffffffff8144cafd>] ? trace_hardirqs_off_thunk+0x3a/0x3c
[<ffffffff8144dde5>] page_fault+0x25/0x30
J. R. Okajima
a.patch.bz2
Description: BZip2 compressed data
------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com
