Hi, I was asked about situations "use cases" that would cause BTRFS to slow down to a crawl. And it's exactly what happened to me yesterday when I was trying, on the contrary, to speed it up. So here's the recipe for getting a "slow to the point it is unusable" BTRFS. 1/ Perform a clean, fresh install of a recent distro with a 3.13 kernel (i.e. Fedora 20) and a BTRFS root filesystem. 2/ Choose the version with a KDE interface 3/ Configure fstab mountpoints using such options (space_cache will have been manually activated once): / btrfs subvol=FEDORA,noatime,compress=lzo,autodefrag /home btrfs subvol=HOME,noatime,compress=lzo,autodefrag 4/ Use "chattr +C" to make the following directories NOCOW (move the old directory elsewhere, create a new dir, make it nocow, copy files from the old one so they are recreated with nocow, check permissions...): - /home/yourself/.cache - /home/yourself/.local/share/akonadi 5/ Use IMAP mail in Kmail. Seriously process your email (it will be stored using akonadi mysql) 6/ Surf normally the web using Firefox 7/ Install SuSE "snapper" package that will perform a FS snapshot every hour. Configure it so it will snapshot both the root FS subvol and the /home subvol 8/ Use the system for 24 hours and you will know that "hardly usable" means... Especially every hour-on-the-hour when Kmail or Firefox will try to access files that have been recently snapshotted... Your system will be dead with saturated HD access for several *minutes* ...Hope this may help hunting this down... Kind regards. -- Swâmi Petaramesh <swami@xxxxxxxxxxxxxx> http://petaramesh.org PGP 9076E32E -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
