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