similar to: server goes pathological

I''m running into a situation where I can''t unmount a mounted snapshot. It shows "busy" even though neither lsof nor fuser show any open files. Umount -f doesn''t work although umount -l does. Is there anything else I can do to debug this scenario or to clear the busy status myself? Or am I down to rebooting each time? This is on stock ubuntu-10.04, x86.

Is there a limit to the number of snapshots that can exist on a file system concurrently? Did I read something here recently about a limit to the number of paths by which a file could be known? If there are limits, then what happens when I bump into or exceed that limit? --rich -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to

Hello, I habe the problems described in here https://btrfs.wiki.kernel.org/index.php/Gotchas: Files with a lot of random writes can become heavily fragmented (10000+ extents) causing trashing on HDDs and excessive multi-second spikes of CPU load on systems with an SSD or large amount a RAM. On servers and workstations this affects databases and virtual machine images. The nodatacow mount option

When I try to umount btrfs filesystem I get always this error with kernel 3.11.4 and 3.11.3, but I can mount and umount without error on kernel 3.11.2. Exact error messages are: BUG: soft lockup - CPU#0 stuck for 23s! [btrfs-transacti:680] BUG: soft lockup - CPU#1 stuck for 23s! [umount:1575] I''m on Fedora 19 I have run scrub and there are no errors: # btrfs scrub status /home scrub

Hiya, Recently, a btrfs file system of mine started to behave very poorly with some btrfs kernel tasks taking 100% of CPU time. # btrfs fi show /dev/sdb Label: none uuid: b3ce8b16-970e-4ba8-b9d2-4c7de270d0f1 Total devices 3 FS bytes used 4.25TB devid 2 size 2.73TB used 1.52TB path /dev/sdc devid 1 size 2.70TB used 1.49TB path /dev/sda4 devid 3 size

After doing something silly (not sure what yet) with a server''s 4-drive btrfs raid1 root, I''ve been booting off a 5th drive (also on btrfs) while poking at the original array. I''ve found that errors triggered by poking around on the mounted-but-broken 4-drive raid (on /mnt) cause the system to gradually lock up. This is a 2.6.37rc8 build without any extra patches;

Dear Devs, I have x4 4TB HDDs formatted with: mkfs.btrfs -L bu-16TB_0 -d raid1 -m raid1 /dev/sd[cdef] /etc/fstab mounts with the options: noatime,noauto,space_cache,inode_cache All on kernel 3.8.13. Upon using rsync to copy some heavily hardlinked backups from ReiserFS, I''ve seen: The following "block rsv returned -28" is repeated 7 times until there is a call trace

Hi everybody, we are using a btrfs RAID 1 with four 2TB hard drives (WD Caviar green and one Red) on a Debian 7.2 with Kernel 3.12.0 Last week I replaced a broken Harddrive with btrfs replace ... After that I wanted to balance the filesystem and get a ''Speicherzugriffsfehler'' (Segmentation fault). After that I want to reboot the system and nothing happens, it hangs at a btrfs

Hi all, I''m running btrfs in a 3-disk RAID1 configuration. After a hard power-off, I''m seeing a lot of hung I/O tasks on this volume, apparently due to a corrupt leaf. I first noticed the problem on kernel 3.4.7, and it''s persisted with 3.4.8. Relevant parts of the kernel log follow. [ 85.179621] block group 38684065792 has an wrong amount of free space [

Hi, I tried very promising btrfs to test it a little and I experienced a little bug in implementation. I''m not sure where the bug lies however this works quite well to reproduce the problem: dd if=/dev/zero of=mountme bs=4k count=100000 dd if=/dev/zero of=mountme2 bs=4k count=100000 mkfs.btrfs mountme mkfs.btrfs mountme2 mkdir loop loop2 mount -o loop mountme loop mount -o loop mountme

Welcome, What are perspectives on BTRFS complying with laptop-mode and stop writing to disk every 30 sec? The thread was asked several years before (http://mailman.samwel.tk/pipermail/laptop-mode/2012-February/000520.html), but time went by and maybe the situation became a little more on the bright side...? With kernel 3.8.11 I can still see with lm-profiler a lot of

Hi, I''ve been running btrfs on one of my machines for a few months now but I keep hitting performance issues. My system quite frequently freezes due to IO starvation. Looking at iotop it tends to show the large majority of the disk I/O being taken up with various btrfs tasks peeking at 7-8M/s, namely: btrfs-endio-wri btrfs-delayed-m btrfs-transacti btrfs-cleaner

Hello On my HP Compaq dc5800 with Ubuntu 13.04 and their 3.8.0-19-lowlatency kernel, I''ve got quite some kernel traces in the syslog. You can find them below or at http://pastebin.com/bLXPBX67 (to avoid line breaks…). These kernel traces all begin with: WARNING: at fs/btrfs/free-space-cache.c:921 __btrfs_write_out_cache+0x6b9/0x9a0 [btrfs]() Most of the time, it starts with: Call

On 06/21/2011 01:15 PM, Jan Stilow wrote: > Hello, > > Nirbheek Chauhan <nirbheek <at> gentoo.org> writes: >> [...] >> >> Every few minutes, (I guess) when applications do fsync (firefox, >> xchat, vim, etc), all applications that use fsync() hang for several >> seconds, and applications that use general IO suffer extreme >> slowdowns.

I''m on Fedora''s 3.8.5-201.fc18.x86_64. I tried to do some not-very-heavy I/O on my system (i.e. save kernel/sys.c in emacs) and it took about a minute. Everything went downhill from there. My system was basically idle at the time. (I have very little in the way of diagnostics because I couldn''t do much but hit the reset button after a couple of minutes.) On

I tried to unmount a btrfs filesystem located in a external usb hard drive. This belonged to a raid1 data and metadata filesystem mounted in degraded mode. Unfortunately, I couldn''t save the image of filesystem but I could see this error in kern.log: Aug 4 02:23:55 rohan kernel: [ 3747.840027] usb 1-3: new high-speed USB device number 8 using ehci_hcd Aug 4 02:23:55 rohan kernel: [

Is this useful to anyone? Got this after a crash/reboot: if (block_rsv) { WARN_ON(block_rsv->size > 0); <<<<<<<<<<<<<<<<<<<<<< btrfs_free_block_rsv(root, block_rsv); } ------------[ cut here ]------------ WARNING: at fs/btrfs/inode.c:2165 btrfs_orphan_commit_root+0xcb/0xdf() Hardware name: 2429A78 Modules linked in:

Christoph Hellwig wrote: > There are a lot of variables when using qemu. > > The most important one are: > > - the cache mode on the device. The default is cache=writethrough, > which is not quite optimal. You generally do want to use cache=none > which uses O_DIRECT in qemu. > - if the backing image is sparse or not. > - if you use barrier - both in the host

I have a system running the Debian package of 3.11.5 with an Amd Opteron 1212 processor (2*64bit cores), 8G of RAM, and an Intel 120G SSD for the root and home subvols. It has a RAID-1 array of 2*3TB disks for bulk storage (movies etc) but that probably isn''t relevant to this problem. On the root filesystem I have cron jobs making daily snapshots of / and /home and additional

On 06/30/2011 09:13 PM, Josef Bacik wrote: > On 06/30/2011 10:12 AM, Proskurin Kirill wrote: >> On 06/29/2011 08:14 PM, Josef Bacik wrote: >>>> Ok - I upgrade to 2.6.39-2 but it is seems to all things get worse. >>>> Now I see [btrfs-transacti]& btrfs-endio-wri] 80-100% all the time and >>>> io performance looks like lower then before.