Re: btrfs-transaction blocked for more than 120 seconds
Sulla posted on Wed, 01 Jan 2014 20:08:21 + as excerpted: > Dear Duncan! > > Thanks very much for your exhaustive answer. > > Hm, I also thought of fragmentation. Alhtough I don't think this is > really very likely, as my server doesn't serve things that likely cause > fragmentation. > It is a mailserver (but only maildir-format), fileserver for windows > clients (huge files that hardly don't get rewritten), a server for > TV-records (but only copy recordings from a sat receiver after they have > been recorded, so no heavy rewriting here), a tiny webserver and all > kinds of such things, but not a storage for huge databases, virtual > machines or a target for filesharing clients. > It however serves as a target for a hardlink-based backupprogram run on > windows PCs, but only once per month or so, so that shouldn't bee too > much. One thing I didn't mention originally, was how to check for fragmentation. filefrag is part of e2fsprogs, and does the trick -- with one caveat. filefrag currently doesn't know about btrfs compression, and interprets each 128 KiB block as a separate extent. So if you have btrfs compression turned on and check a (larger than 128 KiB) file that btrfs has compressed, filefrag will falsely report fragmentation. If in doubt, you can always try defragging that individual file and see if filefrag reports fewer extents or not. If it has fewer extents you know it was fragmented, if not... With that you should actually be able to check some of those big files that you don't think are fragmented, to see. > The problem must lie somewhere on the root partition itslef, because the > system is already slow before mounting the fat data-partitions. > > I'll give the defragmentation a try. But > # sudo btrfs filesystem defrag -r > doesn't work, because "-r" is an unknown option (I'm running Btrfs > v0.20-rc1 on an Ubuntu 3.11.0-14-generic kernel). The -r option was added quite recently. As the wiki (at https://btrfs.wiki.kernel.org ) urges, btrfs is a development filesystem and people choosing to test it should really try to keep current, both because you're unnecessarily putting the data you're testing on btrfs at risk when running old versions with bugs patched in newer versions (that part's mostly for the kernel, tho), and because as a tester, when things /do/ go wrong and you report it, the reports are far more useful if you're running a current version. Kernal 3.11.0 is old. 3.12 has been out for well over a month now. And the btrfs-progs userspace recently switched to kernel-synced versioning as well, with version 3.12 the latest version, which also happens to be the first kernel-version-synced version. That's assuming you don't choose to run the latest git version of the userspace, and the Linus kernel RCs, which many btrfs testers do. (Tho last I updated btrfs-progs, about a week ago, the last git commit was still the version bump to 3.12, but I'm running a git kernel at version 3.13.0-rc5 plus 69 commits.) So you are encouraged to update. =:^) However, if you don't choose to upgrade ... (see next) > I'm doing a # sudo btrfs filesystem defrag / & > on the root directory at the moment. ... Before the -r option was added, btrfs filesystem defrag would only defrag the specific file it was pointed at. If pointed at a directory, it would defrag the directory metadata, but not files or subdirs below it. The way to defrag the entire system then, involved a rather more complicated command using find to output a list of everything on the system, and run defrag individually on each item listed. It's on the wiki. Let's see if I can find it... (yes, but note the wrapped link): https://btrfs.wiki.kernel.org/index.php/ UseCases#How_do_I_defragment_many_files.3F sudo find [subvol [subvol]…] -xdev -type f -exec btrfs filesystem defragment -- {} + As the wiki warns, that doesn't recurse into subvolumes (the -xdev keeps it from going onto non-btrfs filesystems but also keeps it from going into subvolumes), but you can list them as paths where noted. > Question: will this defragment everything or just the root-fs and will I > need to run a defragment on /home as well, as /home is a separate btrfs > filesystem? Well, as noted your command doesn't really defragment that much. But the find command should defragment everything on the named subvolumes. But of course this is where that bit I mentioned in the original post about possibly taking hours with multiple terabytes on spinning rust comes in too. It could take awhile, and when it gets to really fragmented files, it'll probably trigger the same sort of stalls that has us discussing the whole thing in the first place, so the system may not be exactly usable. =:^( > I've also added autodefrag mountoptions and will do a "mount -a" after > the defragmentation. > > I've considered a # sudo btrfs balance start as well, would this do any > good? How close should I let the data fill the parti
Re: Migrate to bcache: A few questions
Austin S Hemmelgarn posted on Wed, 01 Jan 2014 15:12:40 -0500 as excerpted: > On 12/30/2013 11:02 AM, Austin S Hemmelgarn wrote: >> >> As an alternative to using bcache, you might try something simmilar to >> the following: >> 64G SSD with /boot, /, and /usr Other HDD with /var, /usr/portage, >> /usr/src, and /home tmpfs or ramdisk for /tmp and /var/tmp >> This is essentially what I use now, and I have found that it >> significantly improves system performance. >> > On this specific note, I would actually suggest against putting the > portage tree on btrfs, it makes syncing go ridiculously slow, > and it also seems to slow down emerge as well. Interesting observation. I had not see it here (with the gentoo tree and overlays on btrfs), but that's very likely because all my btrfs are on SSD, as I upgraded to both at the same time, because my previous default filesystem choice, reiserfs, isn't well suited to SSD due to excessive writing due to the journaling. I do know slow syncs and portage dep-calculations were one of the reasons I switched to SSD (and thus btrfs), however. That was getting pretty painful on spinning rust, at least with reiserfs. And I imagine btrfs on single-device spinning rust would if anything be worse at least for syncs, due to the default dup metadata, meaning at least three writes (and three seeks) for each file, once for the data, twice for the metadata. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs-transaction blocked for more than 120 seconds
Am 31.12.2013 12:46, schrieb Sulla: Dear all! On my Ubuntu Server 13.10 I use a RAID5 blockdevice consisting of 3 WD20EARS drives. On this I built a LVM and in this LVM I use quite normal partitions /, /home, SWAP (/boot resides on a RAID1.) and also a custom /data partition. Everything (except boot and swap) is on btrfs. sometimes my system hangs for quite some time (top is showing a high wait percentage), then runs on normally. I get kernel messages into /var/log/sylsog, see below. I am unable to make any sense of the kernel messages, there is no reference to the filesystem or drive affected (at least I can not find one). Question: What is happening here? * Is a HDD failing (smart looks good, however) * Is something wrong with my btrfs-filesystem? with which one? * How can I find the cause? Moin Wolfgang, first ot: Happy new Year, over the last celebration days one of our servers (ubuntu 13.04) with custom kernel 3.11.04 did quite simular things, also rais5/raid6. Our Problem was writing to backup showed quit the same kernelog. Also btrfs-transaction was hanging. Also Filesystem usage with 83% looked fine. But that was not true. After some time eating investigation I found, that BTRFS may have in 3.11.x and other kernels(?) a problem with free block lists and fragmentation. Our Server was able to self recover after defragmentation and compressing run. We had problems with end-of-free blocks. After rebuilding the free block list and running defrag the server got enough free blocks to operate well. To be able to do that, we were forced to use the btrfs-git kernel and also the btrfs-progs from git. (3.13-rcX) I did on 26.12.13: # umount /ar # btrfsck --repair --init-extent-tree /dev/sda1 # mount -o clear_cache,skip_balance,autodefrag /dev/sda1 /ar # btrfs fi defragment -rc /ar/backup But attention, I thougt 83% used space shoud be enough "free blocks", but this was wrong. It seems that BTRFS free Block lists are somewhat errous. Especially "balance" may crash if an file has got too many extents/fragments, and allocating space may also hang if free blocks are running low. During the defragmentation run the response of the Server was getting slow, but did not stop in Read Access. Our state today: root@bk:~# df -m /ar Dateisystem1M-Blöcke Benutzt Verfügbar Verw% Eingehängt auf /dev/sda1 13232966 7213717 3181874 70% /ar root@bk:~# btrfs fi show /ar Label: Archiv+Backup uuid: 72b710aa-49a0-4ff5-a470-231560bfee81 Total devices 5 FS bytes used 6.88TiB devid1 size 2.73TiB used 2.70TiB path /dev/sda1 devid2 size 2.73TiB used 2.70TiB path /dev/sdb1 devid3 size 2.73TiB used 2.70TiB path /dev/sdc1 devid4 size 2.73TiB used 2.70TiB path /dev/sdd1 devid5 size 1.70TiB used 4.25GiB path /dev/sde4 Btrfs v3.12 root@bk:~# btrfs fi df /ar Data, single: total=8.00MiB, used=0.00 Data, RAID5: total=8.10TiB, used=6.87TiB System, single: total=4.00MiB, used=0.00 System, RAID5: total=12.00MiB, used=600.00KiB Metadata, single: total=8.00MiB, used=0.00 Metadata, RAID5: total=12.25GiB, used=10.41GiB Today the server completely recovered to full operation. Is there a plan ongoing to hangle such out of free blocks/space situations more comfortable? TIA J. Sauer -- Jürgen Sauer - automatiX GmbH, +49-4209-4699, juergen.sa...@automatix.de Geschäftsführer: Jürgen Sauer, Gerichtstand: Amtsgericht Walsrode • HRB 120986 Ust-Id: DE191468481 • St.Nr.: 36/211/08000 GPG Public Key zur Signaturprüfung: http://www.automatix.de/juergen_sauer_publickey.gpg -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Btrfs: improve the performance fluctuating of the fsync
Leonidas Spyropoulos wrote (ao): > Will this help with apt-get performance over btrfs file system? As far > as I understand it it's happening because of multiple fsync calls. apt-get install eatmydata "This package contains a small LD_PRELOAD library (libeatmydata) and a couple of helper utilities designed to transparently disable fsync and friends (like open(O_SYNC))." Then use it like: eatmydata apt-get install -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Migrate to bcache: A few questions
On 2014-01-02 03:49, Duncan wrote: > Austin S Hemmelgarn posted on Wed, 01 Jan 2014 15:12:40 -0500 as > excerpted: > >> On 12/30/2013 11:02 AM, Austin S Hemmelgarn wrote: >>> >>> As an alternative to using bcache, you might try something simmilar to >>> the following: >>> 64G SSD with /boot, /, and /usr Other HDD with /var, /usr/portage, >>> /usr/src, and /home tmpfs or ramdisk for /tmp and /var/tmp >>> This is essentially what I use now, and I have found that it >>> significantly improves system performance. >>> >> On this specific note, I would actually suggest against putting the >> portage tree on btrfs, it makes syncing go ridiculously slow, >> and it also seems to slow down emerge as well. > > Interesting observation. > > I had not see it here (with the gentoo tree and overlays on btrfs), but > that's very likely because all my btrfs are on SSD, as I upgraded to both > at the same time, because my previous default filesystem choice, > reiserfs, isn't well suited to SSD due to excessive writing due to the > journaling. > > I do know slow syncs and portage dep-calculations were one of the reasons > I switched to SSD (and thus btrfs), however. That was getting pretty > painful on spinning rust, at least with reiserfs. And I imagine btrfs on > single-device spinning rust would if anything be worse at least for > syncs, due to the default dup metadata, meaning at least three writes > (and three seeks) for each file, once for the data, twice for the > metadata. > I think the triple seek+write is probably the biggest offender in my case, although COW and autodefrag probably don't help either. I'm kind of hesitant to put stuff that gets changed daily on a SSD, so I've ended up putting portage on ext4 with no journaling (which out-performs every other filesystem I have tested WRT write performance). As for the dep-calculations, I have 16G of ram, so I just use a script to read the entire tree into the page cache after each sync. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v8 00/14] Online(inband) data deduplication
Hello, I am trying to test your patches and they do not apply to latest 3.12 source or 3.13 git. Am I doing something wrong? ---logs for 3.12--- Hunk #1 succeeded at 59 with fuzz 2 (offset 1 line). patching file init/Kconfig Hunk #1 succeeded at 1085 (offset 96 lines). Hunk #2 succeeded at 1096 (offset 96 lines). patching file fs/btrfs/ctree.h Hunk #1 FAILED at 3692. 1 out of 1 hunk FAILED -- saving rejects to file fs/btrfs/ctree.h.rej patching file fs/btrfs/extent-tree.c Hunk #1 FAILED at 5996. Hunk #2 FAILED at 6023. 2 out of 2 hunks FAILED -- saving rejects to file fs/btrfs/extent-tree.c.rej patching file fs/btrfs/file-item.c Hunk #1 FAILED at 887. Hunk #2 succeeded at 765 with fuzz 2 (offset -151 lines). Hunk #3 FAILED at 978. Hunk #4 FAILED at 1061. Hunk #5 FAILED at 1094. 4 out of 5 hunks FAILED -- saving rejects to file fs/btrfs/file-item.c.rej patching file fs/btrfs/inode.c Hunk #1 FAILED at 969. Hunk #2 FAILED at 2364. 2 out of 2 hunks FAILED -- saving rejects to file fs/btrfs/inode.c.rej ---logs for 3.13--- Hunk #1 succeeded at 59 with fuzz 2 (offset 1 line). patching file init/Kconfig Hunk #1 succeeded at 1078 (offset 89 lines). Hunk #2 succeeded at 1089 (offset 89 lines). patching file fs/btrfs/ctree.h Hunk #1 FAILED at 3692. 1 out of 1 hunk FAILED -- saving rejects to file fs/btrfs/ctree.h.rej patching file fs/btrfs/extent-tree.c Hunk #1 FAILED at 5996. Hunk #2 FAILED at 6023. 2 out of 2 hunks FAILED -- saving rejects to file fs/btrfs/extent-tree.c.rej patching file fs/btrfs/file-item.c Hunk #1 FAILED at 887. Hunk #2 succeeded at 768 with fuzz 2 (offset -148 lines). Hunk #3 FAILED at 978. Hunk #4 FAILED at 1061. Hunk #5 FAILED at 1094. 4 out of 5 hunks FAILED -- saving rejects to file fs/btrfs/file-item.c.rej patching file fs/btrfs/inode.c Hunk #1 FAILED at 969. Hunk #2 FAILED at 2364. 2 out of 2 hunks FAILED -- saving rejects to file fs/btrfs/inode.c.rej On 30/12/2013 10:12 πμ, Liu Bo wrote: Hello, Here is the New Year patch bomb :-) Data deduplication is a specialized data compression technique for eliminating duplicate copies of repeating data.[1] This patch set is also related to "Content based storage" in project ideas[2], it introduces inband data deduplication for btrfs and dedup/dedupe is for short. PATCH 1 is a hang fix with deduplication on, but it's also useful without dedup in practice use. PATCH 2 and 3 are targetting delayed refs' scalability problems, which are uncovered by the dedup feature. PATCH 4 is a speed-up improvement, which is about dedup and quota. PATCH 5-8 is the preparation work for dedup implementation. PATCH 9 shows how we implement dedup feature. PATCH 10 fixes a backref walking bug with dedup. PATCH 11 fixes a free space bug of dedup extents on error handling. PATCH 12 adds the ioctl to control dedup feature. PATCH 13 fixes the metadata ENOSPC problem with dedup which has been there WAY TOO LONG. PATCH 14 fixes a race bug on dedup writes. And there is also a btrfs-progs patch(PATCH 15) which offers all details about how to control the dedup feature. I've tested this with xfstests by adding a inline dedup 'enable & on' in xfstests' mount and scratch_mount. TODO: * a bit-to-bit comparison callback. All comments are welcome! [1]: http://en.wikipedia.org/wiki/Data_deduplication [2]: https://btrfs.wiki.kernel.org/index.php/Project_ideas#Content_based_storage v8: - fix the race crash of dedup ref again. - fix the metadata ENOSPC problem with dedup. v7: - rebase onto the lastest btrfs - break a big patch into smaller ones to make reviewers happy. - kill mount options of dedup and use ioctl method instead. - fix two crash due to the special dedup ref For former patch sets: v6: http://thread.gmane.org/gmane.comp.file-systems.btrfs/27512 v5: http://thread.gmane.org/gmane.comp.file-systems.btrfs/27257 v4: http://thread.gmane.org/gmane.comp.file-systems.btrfs/25751 v3: http://comments.gmane.org/gmane.comp.file-systems.btrfs/25433 v2: http://comments.gmane.org/gmane.comp.file-systems.btrfs/24959 Liu Bo (14): Btrfs: skip merge part for delayed data refs Btrfs: improve the delayed refs process in rm case Btrfs: introduce a head ref rbtree Btrfs: disable qgroups accounting when quata_enable is 0 Btrfs: introduce dedup tree and relatives Btrfs: introduce dedup tree operations Btrfs: introduce dedup state Btrfs: make ordered extent aware of dedup Btrfs: online(inband) data dedup Btrfs: skip dedup reference during backref walking Btrfs: don't return space for dedup extent Btrfs: add ioctl of dedup control Btrfs: fix dedupe 'ENOSPC' problem Btrfs: fix a crash of dedup ref fs/btrfs/backref.c | 9 + fs/btrfs/ctree.c | 2 +- fs/btrfs/ctree.h | 86 ++ fs/btrfs/delayed-ref.c | 161 +++ fs/btrfs/delayed-ref.h | 8 + fs/btrfs/disk-io.c | 40 +++ fs/btrfs/extent-tree.c | 208 -- fs/btrfs/extent_io.c | 22 +
Re: [RFC PATCH v8 00/14] Online(inband) data deduplication
Sorry for the spam, i just mixed up the order of your patches. they now apply cleanly to 3.13 git. Thanks On 2/1/2014 4:32 μμ, Konstantinos Skarlatos wrote: Hello, I am trying to test your patches and they do not apply to latest 3.12 source or 3.13 git. Am I doing something wrong? ---logs for 3.12--- Hunk #1 succeeded at 59 with fuzz 2 (offset 1 line). patching file init/Kconfig Hunk #1 succeeded at 1085 (offset 96 lines). Hunk #2 succeeded at 1096 (offset 96 lines). patching file fs/btrfs/ctree.h Hunk #1 FAILED at 3692. 1 out of 1 hunk FAILED -- saving rejects to file fs/btrfs/ctree.h.rej patching file fs/btrfs/extent-tree.c Hunk #1 FAILED at 5996. Hunk #2 FAILED at 6023. 2 out of 2 hunks FAILED -- saving rejects to file fs/btrfs/extent-tree.c.rej patching file fs/btrfs/file-item.c Hunk #1 FAILED at 887. Hunk #2 succeeded at 765 with fuzz 2 (offset -151 lines). Hunk #3 FAILED at 978. Hunk #4 FAILED at 1061. Hunk #5 FAILED at 1094. 4 out of 5 hunks FAILED -- saving rejects to file fs/btrfs/file-item.c.rej patching file fs/btrfs/inode.c Hunk #1 FAILED at 969. Hunk #2 FAILED at 2364. 2 out of 2 hunks FAILED -- saving rejects to file fs/btrfs/inode.c.rej ---logs for 3.13--- Hunk #1 succeeded at 59 with fuzz 2 (offset 1 line). patching file init/Kconfig Hunk #1 succeeded at 1078 (offset 89 lines). Hunk #2 succeeded at 1089 (offset 89 lines). patching file fs/btrfs/ctree.h Hunk #1 FAILED at 3692. 1 out of 1 hunk FAILED -- saving rejects to file fs/btrfs/ctree.h.rej patching file fs/btrfs/extent-tree.c Hunk #1 FAILED at 5996. Hunk #2 FAILED at 6023. 2 out of 2 hunks FAILED -- saving rejects to file fs/btrfs/extent-tree.c.rej patching file fs/btrfs/file-item.c Hunk #1 FAILED at 887. Hunk #2 succeeded at 768 with fuzz 2 (offset -148 lines). Hunk #3 FAILED at 978. Hunk #4 FAILED at 1061. Hunk #5 FAILED at 1094. 4 out of 5 hunks FAILED -- saving rejects to file fs/btrfs/file-item.c.rej patching file fs/btrfs/inode.c Hunk #1 FAILED at 969. Hunk #2 FAILED at 2364. 2 out of 2 hunks FAILED -- saving rejects to file fs/btrfs/inode.c.rej On 30/12/2013 10:12 πμ, Liu Bo wrote: Hello, Here is the New Year patch bomb :-) Data deduplication is a specialized data compression technique for eliminating duplicate copies of repeating data.[1] This patch set is also related to "Content based storage" in project ideas[2], it introduces inband data deduplication for btrfs and dedup/dedupe is for short. PATCH 1 is a hang fix with deduplication on, but it's also useful without dedup in practice use. PATCH 2 and 3 are targetting delayed refs' scalability problems, which are uncovered by the dedup feature. PATCH 4 is a speed-up improvement, which is about dedup and quota. PATCH 5-8 is the preparation work for dedup implementation. PATCH 9 shows how we implement dedup feature. PATCH 10 fixes a backref walking bug with dedup. PATCH 11 fixes a free space bug of dedup extents on error handling. PATCH 12 adds the ioctl to control dedup feature. PATCH 13 fixes the metadata ENOSPC problem with dedup which has been there WAY TOO LONG. PATCH 14 fixes a race bug on dedup writes. And there is also a btrfs-progs patch(PATCH 15) which offers all details about how to control the dedup feature. I've tested this with xfstests by adding a inline dedup 'enable & on' in xfstests' mount and scratch_mount. TODO: * a bit-to-bit comparison callback. All comments are welcome! [1]: http://en.wikipedia.org/wiki/Data_deduplication [2]: https://btrfs.wiki.kernel.org/index.php/Project_ideas#Content_based_storage v8: - fix the race crash of dedup ref again. - fix the metadata ENOSPC problem with dedup. v7: - rebase onto the lastest btrfs - break a big patch into smaller ones to make reviewers happy. - kill mount options of dedup and use ioctl method instead. - fix two crash due to the special dedup ref For former patch sets: v6: http://thread.gmane.org/gmane.comp.file-systems.btrfs/27512 v5: http://thread.gmane.org/gmane.comp.file-systems.btrfs/27257 v4: http://thread.gmane.org/gmane.comp.file-systems.btrfs/25751 v3: http://comments.gmane.org/gmane.comp.file-systems.btrfs/25433 v2: http://comments.gmane.org/gmane.comp.file-systems.btrfs/24959 Liu Bo (14): Btrfs: skip merge part for delayed data refs Btrfs: improve the delayed refs process in rm case Btrfs: introduce a head ref rbtree Btrfs: disable qgroups accounting when quata_enable is 0 Btrfs: introduce dedup tree and relatives Btrfs: introduce dedup tree operations Btrfs: introduce dedup state Btrfs: make ordered extent aware of dedup Btrfs: online(inband) data dedup Btrfs: skip dedup reference during backref walking Btrfs: don't return space for dedup extent Btrfs: add ioctl of dedup control Btrfs: fix dedupe 'ENOSPC' problem Btrfs: fix a crash of dedup ref fs/btrfs/backref.c | 9 + fs/btrfs/ctree.c | 2 +- fs/btrfs/ctree.h | 86 ++ fs/btrfs/delayed-ref.c | 16
Re: [PATCH RESEND] btrfs: remove dead code
On Wed, Jan 01, 2014 at 05:22:18PM +0100, Michal Nazarewicz wrote: > > On Wed, Jan 1, 2014 at 5:19 AM, Michal Nazarewicz wrote: > >> [commit 8185554d: fix incorrect inode acl reset] introduced a dead > >> code by adding a condition which can never be true to an else > >> branch. The condition can never be true because it is already > >> checked by a previous if statement which causes function to return. > > On Wed, Jan 01 2014, Filipe David Manana wrote: > > Josef already added this patch to btrfs-next weeks ago: > > > > http://git.kernel.org/cgit/linux/kernel/git/josef/btrfs-next.git/commit/?id=c4a886e433dce2b902324a54ef2d13691a760312 > > Ah, sorry for the spam then. > > The original thread did not mention it and this commit was not included > in linux-next's master branch. FYI, the patches get merged to btrfs-next without confirmations to the mailiglist, the linux-next tree does not merge the development branches, only when Chris publishes a branch named 'next'. (http://linux.f-seidel.de/linux-next/pmwiki/pmwiki.php?n=Linux-next.IncludedTrees) david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] btrfs: Add "barrier" option to support "-o remount,barrier"
On Thu, Dec 26, 2013 at 02:45:10PM +0800, Qu Wenruo wrote: > Btrfs can be remounted without barrier, but there is no "barrier" option > so nobody can remount btrfs back with barrier on. Only umount and > mount again can re-enable barrier.(Quite awkward) Ok for adding the mount option. > Reported-by: Daniel Blueman > Signed-off-by: Qu Wenruo > --- > Documentation/filesystems/btrfs.txt | 6 ++ > fs/btrfs/super.c| 8 +++- > 2 files changed, 13 insertions(+), 1 deletion(-) > > diff --git a/Documentation/filesystems/btrfs.txt > b/Documentation/filesystems/btrfs.txt > index 5dd282d..f6f71d6 100644 > --- a/Documentation/filesystems/btrfs.txt > +++ b/Documentation/filesystems/btrfs.txt > @@ -51,6 +51,12 @@ Unless otherwise specified, all options default to off. > defrag process. Works best for small files; Not well suited for > large database workloads. > > + barrier > + Enable the use of block layer write barriers. Write barriers ensure > + that certain IOs make it through the device cache and are on persistent > + storage. > + Barriers are enabled by default. There's the 'nobarrier' option already, I think it's better to keep the pairing option documentation at one place and mark the default one with (*). Related to that, there should imho be a pairing option for every mount option where it makes sense, so all the combinations work through remount. The defaults do not need to be listed via btrfs_show_options, ie. keep the output same as it is now. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unlinked orphans.
On Mon, Dec 23, 2013 at 10:16:15PM -0800, Nacho Man wrote: > > > On Monday, December 23, 2013 4:39 AM, Hugo Mills wrote: > > On Sun, Dec 22, 2013 at 10:27:17PM -0800, Nacho Man wrote: > > Hello, > > I ran dmesg and saw a bunch of these: > > [564421.874063] BTRFS debug (device sda2): unlinked 32 orphans > > [568021.386733] BTRFS debug (device sda2): unlinked 32 orphans > > [569943.269610] BTRFS debug (device sda2): unlinked 32 orphans > > [570929.840278] BTRFS debug (device sda2): unlinked 32 orphans > > [570942.035251] BTRFS debug (device sda2): unlinked 33 orphans > > [571623.719086] BTRFS debug (device sda2): unlinked 32 orphans > > [572075.684003] BTRFS debug (device sda2): unlinked 32 orphans > > > > I just counted and there's a 175 of them. Do I have to worry? I've been > > working on a toolchain and some other stuff for the PS3 so my hard drive > > was being accessed a bit. Could it be related? Thanks. > > No, this is harmless. Orphans are files that were deleted while > they were still held open by a process. POSIX semantics requires that > the file data is still readable by the process, but that the file's > hardlink(s) are no longer visible -- so there's no way of finding the > file again by "normal" methods. Once the process closes the file, it > is unlinked. > > > Thank you very much. Is there a way to suppress these messages about > orphaned files? I'd still like to see messages if something goes > wrong, just not so much the orphaned files... The message level is 'debug', you can easily filter it out. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unlinked orphans.
On Mon, Dec 23, 2013 at 10:16:33AM -0700, Chris Murphy wrote: > > On Dec 22, 2013, at 11:27 PM, Nacho Man wrote: > > > Hello, > > I ran dmesg and saw a bunch of these: > > [564421.874063] BTRFS debug (device sda2): unlinked 32 orphans > > I sometimes see a similar message (minus debug and device), but it > occurs on every boot (rootfs is on Btrfs) and is persistent. If I > temporarily add mount option recovery, then they get cleaned up. > Expected? Yes. The orphan files are cleaned during mount, so you could see it during boot. There might be orphaned yet uncleaned files left on the filesystem after a normal umount. I don't see how could -o recovery, affect that without any real recovery conditions, it's probably a coincidence that the messages do not appear. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: coredump in btrfsck
On Jan 1, 2014, at 3:35 PM, Oliver Mangold wrote: > On 01.01.2014 22:58, Chris Murphy wrote: >> On Jan 1, 2014, at 2:27 PM, Oliver Mangold wrote: >> >>> I fear, I broke my FS by running btrfsck. I tried 'btrfsck --repair' and it >>> fixed several problems but finally crashed with some debug message from >>> 'extent-tree.c', so I also tried 'btrfsck --repair --init-extent-tree'. >> It is sort of a (near) last restort, you know this right? What did you try >> before btrfsck? Did you set dmesg -n7, then mount -o recovery and if so what >> was recorded in dmesg? > Ehm, actually, no. https://btrfs.wiki.kernel.org/index.php/FAQ#When_will_Btrfs_have_a_fsck_like_tool.3F This is a bit dated, but the general idea is to not use repair except on advice of a developer, and also there are still some risks. Just a week or so ago, one said it was a little dangerous still. So yeah, -o recovery should be the first choice. > Before I ran btrfsck there was no reason to use '-o recovery' or something, > because the filesystem seemed to work. Ahh so you ran btrfsck without --repair first? It found problems so then you next ran it with --repair? > But I was worried after running btrfsck, because the FS apparently was in an > inconsistent state. So I tried 'btrfsck --repair' and when that crashed > 'btrfsck --init-extent-tree'. Didn't know it is considered 'last resort'. It > did the trick for several previous problems and seemed to have no negative > consequences, so I tried it now also. It's sort of a sledgehammer. > But it looks like I can still recover my data with 'btrfs restore', so it's > less critical than assumed. That's good news. > Sorry, that I can't give you the logs you would have liked. Yeah, I'm not certain anyone can give you much advice without more details. What kernel version and btfs-progs were you using at the time of the problem, and the btrfsck? You report a crash but no dmesg of the crash? > Didn't expect anything bad to happen. I would just wsh that btrfsck could fix > that kind of problem. Sure but the problem is unclear, and you have no logs to make it more clear what even happened. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/6] Btrfs: use flags instead of the bool variants in delayed node
On Thu, Dec 26, 2013 at 01:07:05PM +0800, Miao Xie wrote: > +#define BTRFS_DELAYED_NODE_IN_LIST 0 > +#define BTRFS_DELAYED_NODE_INODE_DIRTY 1 > + > struct btrfs_delayed_node { > u64 inode_id; > u64 bytes_reserved; > @@ -65,8 +68,7 @@ struct btrfs_delayed_node { > struct btrfs_inode_item inode_item; > atomic_t refs; > u64 index_cnt; > - bool in_list; > - bool inode_dirty; > + unsigned long flags; > int count; > }; What's the reason to do that? Replacing 2 bools with a bitfield does not seem justified, not from saving memory, nor from a performance gain side. Also some of the bit operations imply the lock instruction prefix so this affects the surrounding items as well. I don't think this is needed, unless you have further plans with the flags item. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Managing large volumes
I am a bit confused and I have probably managed to outsmart myself. For about 15 months, I have been running my system on a single, large btrfs volume. It is RAID-0 on two SATA-III HDD's for a total of 1.9 TB. This is a home system running Siduction (Debian Sid) Linux. While I have root, home, and a special data directory each as separate subvolumes, I am beginning to wonder whether I should have made each of these on separate partitions and separate btrfs filesystems. Am am at a point where I would like to do a fresh install of my OS without losing my home and data contents. And I do not think separate btrfs subvolumes will help me on that. Is that correct? Is there a way to prevent an OS installation from formatting the /home and /data subvolumes while completely replacing the root subvolume? Or do I need to completely repartition my drives so I don't get into this situation, again? Thank you, Tim -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Migrate to bcache: A few questions
Austin S Hemmelgarn posted on Thu, 02 Jan 2014 07:36:06 -0500 as excerpted: > I think the triple seek+write is probably the biggest offender in my > case, although COW and autodefrag probably don't help either. I'm kind > of hesitant to put stuff that gets changed daily on a SSD, so I've ended > up putting portage on ext4 with no journaling (which out-performs every > other filesystem I have tested WRT write performance). I went ahead with the gentoo tree and overlays on SSD, because... well, they need the fast access that SSD provides, and if I can't use the SSD for its good points, why did I buy it in the first place? It's also worth noting that only a few files change on a day to day basis. Most of the tree remains as it is. Similarly with the git pack files behind the overlays (and live-git sources) -- once they reach a certain point they stop changing and all the changes go into a new file. Further, most reports I've seen suggest that daily changes on some reasonably small part of an SSD aren't a huge problem... given wear- leveling and an estimated normal lifetime of say three to five years before they're replaced with new hardware anyway, daily changes simply shouldn't be an issue. It's worth keeping limited-write-cycles in mind and minimizing them where possible, but it's not quite the big thing a lot of people make it out to be. Additionally, I'm near 100% overprovisioned, giving the SSDs lots of room to do that wear-leveling, so... Meanwhile, are you using tail packing on that ext4? The idea of wasting all that space due to all those small files has always been a downer for me and others, and is the reason many of us used reiserfs for many years. I guess ext4 now does have tail packing or some similar solution, but I do wonder how much that tail packing affects performance. Of course it'd also be possible to run reiserfs without tail packing, and even without journaling. But somehow I always thought what was the point of running reiser, if those were disabled. Anyway, I'd find it interesting to benchmark what the effect of tailpacking (or whatever ext4 calls it) on no-journal ext4 for the gentoo tree actually was. If you happen to know, or happen to be inspired to run those benchmarks now, I'd be interested... > As for the > dep-calculations, I have 16G of ram, so I just use a script to read the > entire tree into the page cache after each sync. With 16 gig RAM, won't the sync have pulled everything into page-cache already? That has always seemed to be the case here. Running an emerge --deep --upgrade --newuse @world here after a sync shows very little disk activity and takes far less time than trying the same thing after an unmount/remount, thus cold-cache. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Managing large volumes
On Jan 2, 2014, at 3:28 PM, Tim Cuthbertson wrote: > > Am am at a point where I would like to do a fresh install of my OS > without losing my home and data contents. And I do not think separate > btrfs subvolumes will help me on that. Is that correct? Is there a way > to prevent an OS installation from formatting the /home and /data > subvolumes while completely replacing the root subvolume? Or do I need > to completely repartition my drives so I don't get into this > situation, again? That's up to the installer. e.g. the Fedora installer requires a new subvolume for rootfs which can be either a new or existing Btrfs volume. Existing subvolumes for /home or /data can simply be assigned mountpoints, and behind the scene all that's really happening is an entry is made for them in fstab. So at least in the case of Fedora, it's even possible to install onto an existing Btrfs volume without replacing the prior rootfs until later if you wish. You aren't required to delete it, you only required to make a new one. I'm uncertain how Debian implements this in their installer. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Managing large volumes
Tim Cuthbertson posted on Thu, 02 Jan 2014 16:28:33 -0600 as excerpted: > I am a bit confused and I have probably managed to outsmart myself. For > about 15 months, I have been running my system on a single, large btrfs > volume. It is RAID-0 on two SATA-III HDD's for a total of 1.9 TB. This > is a home system running Siduction (Debian Sid) Linux. While I have > root, home, and a special data directory each as separate subvolumes, I > am beginning to wonder whether I should have made each of these on > separate partitions and separate btrfs filesystems. > > Am am at a point where I would like to do a fresh install of my OS > without losing my home and data contents. And I do not think separate > btrfs subvolumes will help me on that. Is that correct? Is there a way > to prevent an OS installation from formatting the /home and /data > subvolumes while completely replacing the root subvolume? Or do I need > to completely repartition my drives so I don't get into this situation, > again? I'm not running Debian so won't attempt to answer that side of the question. However, count me firmly on the side of independent partitions, here. My thinking isn't so much with reinstallation (I run gentoo so that's not an issue), but on the fact that with subvolumes, it's still the same single huge filesystem tree, and that's *ALL* my data eggs in one filesystem basket! What's worse is that said filesystem basket is still under development and thus even more than the always good sysadmin practice, I must be prepared with tested backups of anything I care about in that filesystem basket, should it turn out to be buggy. Smaller individual filesystems are easier to manage from a backup perspective, especially if only one fails, and take less time to btrfs balance/scrub/whatever as well, so it's easier to keep them in reasonably good health. That said, I know there are people that prefer either subvolumes or putting everything on LVM, as well, primarily because one doesn't have to worry about getting the size exactly correct or having too much space on one partition and too much data on another. They have their valid reasons for what they do, too. I just happen to know what I have found works best for me, after several decades of experience, over which I have had to deal with various disaster recovery situations. I prefer to strictly limit my risk even when playing with still under development filesystems such as btrfs, and independent partitions is simply the most effective way I've found to do that for my own systems and use-cases, but that doesn't mean other people's approaches aren't better for their systems and their use-cases. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Question about ext4 conversion and leaf size
Conversion from ext4 works really well and is an important step for adoption. After recently converting a large-ish device I noticed dodgy performance, even after defragment & rebalance; noticeably different from the quite good performance of a newly-created btrfs with 16k leaf size, as is the default since recently. So I went spelunking and found that the btrfs-convert logic indeed uses the ext4 block size as leaf size (from #2220): https://git.kernel.org/cgit/linux/kernel/git/mason/btrfs-progs.git/tree/btrfs-convert.c#n2245 This is typically 4096 bytes and explains the observed performance. So while I'm basically familiar with btrfs's design, I know nothing about the details of the conversion (I'm amazed that it works so well, including rollback!) but can/should this not be updated to the new default of 16k, or is there a strong necessary correlation between the ext4 block size and the newly created btrfs? thanks! Holger -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] btrfs: Add "barrier" option to support "-o remount,barrier"
On Thu, 2 Jan 2014 16:41:03 +0100, David Sterba wrote: On Thu, Dec 26, 2013 at 02:45:10PM +0800, Qu Wenruo wrote: Btrfs can be remounted without barrier, but there is no "barrier" option so nobody can remount btrfs back with barrier on. Only umount and mount again can re-enable barrier.(Quite awkward) Ok for adding the mount option. Reported-by: Daniel Blueman Signed-off-by: Qu Wenruo --- Documentation/filesystems/btrfs.txt | 6 ++ fs/btrfs/super.c| 8 +++- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt index 5dd282d..f6f71d6 100644 --- a/Documentation/filesystems/btrfs.txt +++ b/Documentation/filesystems/btrfs.txt @@ -51,6 +51,12 @@ Unless otherwise specified, all options default to off. defrag process. Works best for small files; Not well suited for large database workloads. + barrier + Enable the use of block layer write barriers. Write barriers ensure + that certain IOs make it through the device cache and are on persistent + storage. + Barriers are enabled by default. There's the 'nobarrier' option already, I think it's better to keep the pairing option documentation at one place and mark the default one with (*). Related to that, there should imho be a pairing option for every mount option where it makes sense, so all the combinations work through remount. The defaults do not need to be listed via btrfs_show_options, ie. keep the output same as it is now. david Thanks for pointing out these problem. This makes sense.Like space_cache and nospace_cache follows the way you mentioned, but most other options just followed the alphabet order, and a lot of pairing is missing. I'll try to add all the missingpairing and unify mount options in the document. Qu -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Managing large volumes
Tim Cuthbertson schrieb: > I am a bit confused and I have probably managed to outsmart myself. > For about 15 months, I have been running my system on a single, large > btrfs volume. It is RAID-0 on two SATA-III HDD's for a total of 1.9 > TB. This is a home system running Siduction (Debian Sid) Linux. While > I have root, home, and a special data directory each as separate > subvolumes, I am beginning to wonder whether I should have made each > of these on separate partitions and separate btrfs filesystems. > > Am am at a point where I would like to do a fresh install of my OS > without losing my home and data contents. And I do not think separate > btrfs subvolumes will help me on that. Is that correct? Is there a way > to prevent an OS installation from formatting the /home and /data > subvolumes while completely replacing the root subvolume? Or do I need > to completely repartition my drives so I don't get into this > situation, again? How about installing into a new root subvolume? I don't know if the Debian installer allows you to do that. But this way you could easily roll back later, or grab config files from there, or, or... And when you are done, simply remove the old root subvolume or deduplicate it using dedup and keep it around for archival purposes. The one-partition layout is probably okay, tho many installers lack native support for it. But, at least this is how I think about it, take subvolumes as dynamically sized partitions from your storage pool. Just keep in mind you don't want the installer to format your btrfs. You probably want to take a backup of your data first. It is probably possible to bootstrap your Debian installation by first creating your new subvolume, then mount it and use it as bootstrapped destination or chroot into it to run the installation. You could bind-mount your data and home there so it is visible to the installer for it to import your user id. HTH Kai -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Managing large volumes
On Fri, 3 Jan 2014, Tim Cuthbertson wrote: > I am a bit confused and I have probably managed to outsmart myself. > For about 15 months, I have been running my system on a single, large > btrfs volume. It is RAID-0 on two SATA-III HDD's for a total of 1.9 > TB. This is a home system running Siduction (Debian Sid) Linux. While > I have root, home, and a special data directory each as separate > subvolumes, I am beginning to wonder whether I should have made each > of these on separate partitions and separate btrfs filesystems. Why do you use RAID-0? > Am am at a point where I would like to do a fresh install of my OS > without losing my home and data contents. And I do not think separate > btrfs subvolumes will help me on that. Is that correct? Is there a way > to prevent an OS installation from formatting the /home and /data > subvolumes while completely replacing the root subvolume? Or do I need > to completely repartition my drives so I don't get into this > situation, again? A fairly standard OS install feature is to not run mkfs on a partition. So if you had your system configured such that the current root is a subvol and that the root of the BTRFS filesystem has no names that match a regular installation (IE not having /usr etc) then it should just work. Even if you use a /home subvol for the home directories that shouldn't be a real problem as the account creation process shouldn't remove old accounts. One other issue you may have is that you need the installer to have a new enough kernel to support the filesystem. If you install a system from a Debian/Wheezy CD and then upgrade it to Debian/Unstable then I think it gets some new filesystem features that make it impossible to mount with Debian/Wheezy. I recall having to upgrade a Debian/Wheezy system to a Debian/Unstable kernel so it could mount a BTRFS removable device that had been mounted on a Debian/Unstable system. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs-transaction blocked for more than 120 seconds
Duncan <1i5t5.dun...@cox.net> schrieb: > But because a full balance rewrites everything anyway, it'll effectively > defrag too. Is that really true? I thought it just rewrites each distinct extent and shuffels chunks around... This would mean it does not merge extents together. Regards, Kai -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Crash in submit_extent_page.isra (3.12.6)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This occurs sporadically and the machine is somewhat useless as a result since most filesystem operations then hang. For example even reboot fails because it does filesystem operations. kernel is regular kernel.org 3.12.6 compiled with Ubuntu's kernel config. OS is Ubuntu 13.10 AMD64 I have 3 separate btrfs filesystems each with a few subvolumes, and with subvolume snapshots (hourly, daily, weekly etc). No RAID, crypto etc. Kernel BUG at a01268e8 [verbose debug info unavailable] [86961.217522] invalid opcode: [#1] SMP [86961.217536] Modules linked in: pci_stub vboxpci(OF) vboxnetadp(OF) vboxnetflt(OF) vboxdrv(OF) 8021q garp mrp parport_pc ppdev bnep rfcomm bluetooth binfmt_misc snd_hda_codec_hdmi snd_hda_codec_realtek x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel bridge aesni_intel stp aes_x86_64 llc lrw gf128mul glue_helper ablk_helper cryptd eeepc_wmi asus_wmi mxm_wmi sparse_keymap joydev snd_hda_intel snd_hda_codec arc4 snd_usb_audio snd_seq_midi snd_usbmidi_lib snd_hwdep snd_seq_midi_event uvcvideo snd_rawmidi videobuf2_vmalloc ath9k videobuf2_memops snd_pcm videobuf2_core ath9k_common videodev ath9k_hw snd_page_alloc ath mac80211 microcode psmouse serio_raw cfg80211 i915 snd_seq lpc_ich snd_seq_device drm_kms_helper snd_timer drm snd wmi video i2c_algo_bit mac_hid mei_me soundcore mei lp parport hid_generic usbhid hid btrfs libcrc32c raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq e1000e ra i d1 ahci raid0 ptp libahci pps_core multipath linear [86961.217905] CPU: 2 PID: 6825 Comm: btrfs-endio-wri Tainted: GF W O 3.12.6-rogerb #1 [86961.217926] Hardware name: System manufacturer System Product Name/P8Z77-V PRO, BIOS 2003 05/10/2013 [86961.217954] task: 8800a2374710 ti: 88003fbb8000 task.ti: 88003fbb8000 [86961.217985] RIP: 0010:[] [] btrfs_merge_bio_hook+0x78/0x80 [btrfs] [86961.218031] RSP: :88003fbb9638 EFLAGS: 00010282 [86961.218044] RAX: ffea RBX: 1000 RCX: 0006 [86961.218070] RDX: 0007 RSI: 21382136 RDI: 0246 [86961.218108] RBP: 88003fbb9650 R08: 0092 R09: 078f [86961.218126] R10: R11: 88003fbb91e6 R12: 1000 [86961.218156] R13: 8801044e0ba8 R14: 8807f3580040 R15: 1988 [86961.218174] FS: () GS:88081fa8() knlGS: [86961.218193] CS: 0010 DS: ES: CR0: 80050033 [86961.218208] CR2: 7f5b389be000 CR3: 01a3 CR4: 001407e0 [86961.218240] Stack: [86961.218250] 1000 1000 88003fbb9870 88003fbb96a0 [86961.218283] a0141c67 0020 ea0019b1d7c0 [86961.218306] 1988 1000 [86961.218333] Call Trace: [86961.218356] [] submit_extent_page.isra.35+0xb7/0x1e0 [btrfs] [86961.218386] [] __do_readpage+0x245/0x760 [btrfs] [86961.218408] [] ? repair_eb_io_failure+0xb0/0xb0 [btrfs] [86961.218432] [] ? free_root_pointers+0x190/0x190 [btrfs] [86961.218457] [] ? btrfs_lookup_ordered_extent+0x27/0x1e0 [btrfs] [86961.218482] [] __extent_read_full_page+0xc5/0xe0 [btrfs] [86961.218508] [] ? free_root_pointers+0x190/0x190 [btrfs] [86961.218544] [] ? free_root_pointers+0x190/0x190 [btrfs] [86961.218580] [] read_extent_buffer_pages+0x21b/0x300 [btrfs] [86961.218603] [] ? free_root_pointers+0x190/0x190 [btrfs] [86961.218625] [] btree_read_extent_buffer_pages.constprop.55+0xb3/0x120 [btrfs] [86961.218651] [] read_tree_block+0x46/0x80 [btrfs] [86961.218671] [] read_block_for_search.isra.34+0x148/0x380 [btrfs] [86961.218702] [] ? warn_slowpath_common+0x8f/0xa0 [86961.218724] [] btrfs_search_old_slot+0x2c7/0x900 [btrfs] [86961.218747] [] __resolve_indirect_refs+0x11c/0x5c0 [btrfs] [86961.218771] [] find_parent_nodes+0x5ca/0xe70 [btrfs] [86961.218793] [] ? btrfs_submit_bio_hook+0x1e0/0x1e0 [btrfs] [86961.218816] [] iterate_extent_inodes+0xdf/0x250 [btrfs] [86961.218838] [] ? btrfs_submit_bio_hook+0x1e0/0x1e0 [btrfs] [86961.218861] [] iterate_inodes_from_logical+0x87/0xa0 [btrfs] [86961.218883] [] record_extent_backrefs+0x7b/0xf0 [btrfs] [86961.218906] [] btrfs_finish_ordered_io+0x1ef/0xaf0 [btrfs] [86961.218929] [] finish_ordered_fn+0x15/0x20 [btrfs] [86961.218950] [] worker_loop+0x15a/0x5c0 [btrfs] [86961.218971] [] ? btrfs_queue_worker+0x330/0x330 [btrfs] [86961.218988] [] kthread+0xc0/0xd0 [86961.219001] [] ? kthread_create_on_node+0x120/0x120 [86961.219018] [] ret_from_fork+0x7c/0xb0 [86961.219033] [] ? kthread_create_on_node+0x120/0x120 [86961.219049] Code: c9 45 31 c0 89 fe 48 89 c7 4c 89 65 e8 e8 31 77 02 00 85 c0 78 15 4c 01 e3 31 c0 48 3b 5d e8 0f 97 c0 48 83 c4 08 5b 41 5c 5d c3 <0f> 0b 66 0f 1f 44 00 00 0f 1f 44 00
[PATCH v2 00/11] btrfs: Add missing pairing mount options.
Some options should be paired to support triggering different functions when remounting. This patchset add these missing pairing mount options. changelog: v1: Initial commit with only barrier option v2: Add other missing pairing options Qu Wenruo (11): btrfs: Add "barrier" option to support "-o remount,barrier" btrfs: Add noautodefrag mount option. btrfs: Add nocheck_int mount option. btrfs: Add nodiscard mount option. btrfs: Add noenospc_debug mount option. btrfs: Add noflushoncommit mount option. btrfs: Add noinode_cache mount option. btrfs: Add acl mount option. btrfs: Add datacow mount option. btrfs: Add datasum mount option. btrfs: Add treelog mount option. Documentation/filesystems/btrfs.txt | 56 ++-- fs/btrfs/super.c| 74 - 2 files changed, 110 insertions(+), 20 deletions(-) -- 1.8.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/11] btrfs: Add "barrier" option to support "-o remount,barrier"
Btrfs can be remounted without barrier, but there is no "barrier" option so nobody can remount btrfs back with barrier on. Only umount and mount again can re-enable barrier.(Quite awkward) Also the mount options in the document is also changed slightly for the further pairing options changes. Reported-by: Daniel Blueman Signed-off-by: Qu Wenruo Cc: David Sterba --- changelog: v1: Add barrier option v2: Change the document style to fit pairing options better --- Documentation/filesystems/btrfs.txt | 13 +++-- fs/btrfs/super.c| 8 +++- 2 files changed, 14 insertions(+), 7 deletions(-) diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt index 5dd282d..2d2e016 100644 --- a/Documentation/filesystems/btrfs.txt +++ b/Documentation/filesystems/btrfs.txt @@ -38,7 +38,7 @@ Mount Options = When mounting a btrfs filesystem, the following option are accepted. -Unless otherwise specified, all options default to off. +Options with (*) are default options and will not show in the mount options. alloc_start= Debugging option to force all block allocations above a certain @@ -138,12 +138,13 @@ Unless otherwise specified, all options default to off. Disable support for Posix Access Control Lists (ACLs). See the acl(5) manual page for more information about ACLs. + barrier(*) nobarrier -Disables the use of block layer write barriers. Write barriers ensure - that certain IOs make it through the device cache and are on persistent - storage. If used on a device with a volatile (non-battery-backed) - write-back cache, this option will lead to filesystem corruption on a - system crash or power loss. +Disable/enable the use of block layer write barriers. Write barriers + ensure that certain IOs make it through the device cache and are on + persistent storage. If used on a device with a volatile + (non-battery-backed) write-back cache, this option will lead to + filesystem corruption on a system crash or power loss. nodatacow Disable data copy-on-write for newly created files. Implies nodatasum, diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index e9c13fb..fe9d8a6 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -323,7 +323,7 @@ enum { Opt_no_space_cache, Opt_recovery, Opt_skip_balance, Opt_check_integrity, Opt_check_integrity_including_extent_data, Opt_check_integrity_print_mask, Opt_fatal_errors, Opt_rescan_uuid_tree, - Opt_commit_interval, + Opt_commit_interval, Opt_barrier, Opt_err, }; @@ -335,6 +335,7 @@ static match_table_t tokens = { {Opt_nodatasum, "nodatasum"}, {Opt_nodatacow, "nodatacow"}, {Opt_nobarrier, "nobarrier"}, + {Opt_barrier, "barrier"}, {Opt_max_inline, "max_inline=%s"}, {Opt_alloc_start, "alloc_start=%s"}, {Opt_thread_pool, "thread_pool=%d"}, @@ -494,6 +495,11 @@ int btrfs_parse_options(struct btrfs_root *root, char *options) btrfs_clear_opt(info->mount_opt, SSD); btrfs_clear_opt(info->mount_opt, SSD_SPREAD); break; + case Opt_barrier: + if (btrfs_test_opt(root, NOBARRIER)) + btrfs_info(root->fs_info, "turning on barriers"); + btrfs_clear_opt(info->mount_opt, NOBARRIER); + break; case Opt_nobarrier: btrfs_info(root->fs_info, "turning off barriers"); btrfs_set_opt(info->mount_opt, NOBARRIER); -- 1.8.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 02/11] btrfs: Add noautodefrag mount option.
Btrfs has autodefrag mount option but no pairing noautodefrag option, which makes it impossible to disable autodefrag without umount. Signed-off-by: Qu Wenruo --- changelog: v2: Add noauitodefrag mount option --- Documentation/filesystems/btrfs.txt | 8 +--- fs/btrfs/super.c| 8 +++- 2 files changed, 12 insertions(+), 4 deletions(-) diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt index 2d2e016..65e885f 100644 --- a/Documentation/filesystems/btrfs.txt +++ b/Documentation/filesystems/btrfs.txt @@ -46,10 +46,12 @@ Options with (*) are default options and will not show in the mount options. bytes, optionally with a K, M, or G suffix, case insensitive. Default is 1MB. + noautodefrag(*) autodefrag - Detect small random writes into files and queue them up for the - defrag process. Works best for small files; Not well suited for - large database workloads. + Disable/enable auto defragmentation. + Auto defragmentation detects small random writes into files and queue + them up for the defrag process. Works best for small files; + Not well suited for large database workloads. check_int check_int_data diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index fe9d8a6..c65f696 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -323,7 +323,7 @@ enum { Opt_no_space_cache, Opt_recovery, Opt_skip_balance, Opt_check_integrity, Opt_check_integrity_including_extent_data, Opt_check_integrity_print_mask, Opt_fatal_errors, Opt_rescan_uuid_tree, - Opt_commit_interval, Opt_barrier, + Opt_commit_interval, Opt_barrier, Opt_nodefrag, Opt_err, }; @@ -357,6 +357,7 @@ static match_table_t tokens = { {Opt_enospc_debug, "enospc_debug"}, {Opt_subvolrootid, "subvolrootid=%d"}, {Opt_defrag, "autodefrag"}, + {Opt_nodefrag, "noautodefrag"}, {Opt_inode_cache, "inode_cache"}, {Opt_no_space_cache, "nospace_cache"}, {Opt_recovery, "recovery"}, @@ -602,6 +603,11 @@ int btrfs_parse_options(struct btrfs_root *root, char *options) btrfs_info(root->fs_info, "enabling auto defrag"); btrfs_set_opt(info->mount_opt, AUTO_DEFRAG); break; + case Opt_nodefrag: + if (btrfs_test_opt(root, AUTO_DEFRAG)) + btrfs_info(root->fs_info, "disabling auto defrag"); + btrfs_clear_opt(info->mount_opt, AUTO_DEFRAG); + break; case Opt_recovery: btrfs_info(root->fs_info, "enabling auto recovery"); btrfs_set_opt(info->mount_opt, RECOVERY); -- 1.8.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/11] btrfs: Add noenospc_debug mount option.
Add noenospc_debug mount option to disable ENOSPC debug with remount option. Signed-off-by: Qu Wenruo --- changelog: v2: Add noenospc_debug mount option. --- Documentation/filesystems/btrfs.txt | 3 ++- fs/btrfs/super.c| 6 +- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt index 344e67f..14765e6 100644 --- a/Documentation/filesystems/btrfs.txt +++ b/Documentation/filesystems/btrfs.txt @@ -111,8 +111,9 @@ Options with (*) are default options and will not show in the mount options. performance impact. (The fstrim command is also available to initiate batch trims from userspace). + noenospc_debug(*) enospc_debug - Debugging option to be more verbose in some ENOSPC conditions. + Disable/enable debugging option to be more verbose in some ENOSPC conditions. fatal_errors= Action to take when encountering a fatal error: diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index 3ab11d4..fa9c698 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -324,7 +324,7 @@ enum { Opt_check_integrity, Opt_check_integrity_including_extent_data, Opt_check_integrity_print_mask, Opt_fatal_errors, Opt_rescan_uuid_tree, Opt_commit_interval, Opt_barrier, Opt_nodefrag, Opt_nocheck_integrity, - Opt_nodiscard, + Opt_nodiscard, Opt_noenospc_debug, Opt_err, }; @@ -357,6 +357,7 @@ static match_table_t tokens = { {Opt_clear_cache, "clear_cache"}, {Opt_user_subvol_rm_allowed, "user_subvol_rm_allowed"}, {Opt_enospc_debug, "enospc_debug"}, + {Opt_noenospc_debug, "noenospc_debug"}, {Opt_subvolrootid, "subvolrootid=%d"}, {Opt_defrag, "autodefrag"}, {Opt_nodefrag, "noautodefrag"}, @@ -605,6 +606,9 @@ int btrfs_parse_options(struct btrfs_root *root, char *options) case Opt_enospc_debug: btrfs_set_opt(info->mount_opt, ENOSPC_DEBUG); break; + case Opt_noenospc_debug: + btrfs_clear_opt(info->mount_opt, ENOSPC_DEBUG); + break; case Opt_defrag: btrfs_info(root->fs_info, "enabling auto defrag"); btrfs_set_opt(info->mount_opt, AUTO_DEFRAG); -- 1.8.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 10/11] btrfs: Add datasum mount option.
Add datasum mount option to enable checksum with remount option. Signed-off-by: Qu Wenruo --- changelog: v2: Add datasum mount option. --- Documentation/filesystems/btrfs.txt | 4 +++- fs/btrfs/super.c| 11 ++- 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt index 48c1833..480eeda 100644 --- a/Documentation/filesystems/btrfs.txt +++ b/Documentation/filesystems/btrfs.txt @@ -164,8 +164,10 @@ Options with (*) are default options and will not show in the mount options. Enable/disable data copy-on-write for newly created files. Nodatacow implies nodatasum, and disables all compression. + datasum(*) nodatasum - Disable data checksumming for newly created files. + Enable/disable data checksumming for newly created files. + Datasum implies datacow. notreelog Disable the tree logging used for fsync and O_SYNC writes. diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index cb4c90d..01ae900 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -325,7 +325,7 @@ enum { Opt_check_integrity_print_mask, Opt_fatal_errors, Opt_rescan_uuid_tree, Opt_commit_interval, Opt_barrier, Opt_nodefrag, Opt_nocheck_integrity, Opt_nodiscard, Opt_noenospc_debug, Opt_noflushoncommit, - Opt_noinode_cache, Opt_acl, Opt_datacow, + Opt_noinode_cache, Opt_acl, Opt_datacow, Opt_datasum, Opt_err, }; @@ -335,6 +335,7 @@ static match_table_t tokens = { {Opt_subvolid, "subvolid=%s"}, {Opt_device, "device=%s"}, {Opt_nodatasum, "nodatasum"}, + {Opt_datasum, "datasum"}, {Opt_nodatacow, "nodatacow"}, {Opt_datacow, "datacow"}, {Opt_nobarrier, "nobarrier"}, @@ -437,6 +438,14 @@ int btrfs_parse_options(struct btrfs_root *root, char *options) btrfs_info(root->fs_info, "setting nodatasum"); btrfs_set_opt(info->mount_opt, NODATASUM); break; + case Opt_datasum: + if (btrfs_test_opt(root, NODATACOW)) + btrfs_info(root->fs_info, "setting datasum, datacow enabled"); + else + btrfs_info(root->fs_info, "setting datasum"); + btrfs_clear_opt(info->mount_opt, NODATACOW); + btrfs_clear_opt(info->mount_opt, NODATASUM); + break; case Opt_nodatacow: if (!btrfs_test_opt(root, COMPRESS) || !btrfs_test_opt(root, FORCE_COMPRESS)) { -- 1.8.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/11] btrfs: Add noflushoncommit mount option.
Add noflushoncommit mount option to disable flush on commit with remount option. Signed-off-by: Qu Wenruo --- changelog: v2: Add noflushoncommit mount option. --- Documentation/filesystems/btrfs.txt | 1 + fs/btrfs/super.c| 8 +++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt index 14765e6..516ed65 100644 --- a/Documentation/filesystems/btrfs.txt +++ b/Documentation/filesystems/btrfs.txt @@ -120,6 +120,7 @@ Options with (*) are default options and will not show in the mount options. "bug" - BUG() on a fatal error. This is the default. "panic" - panic() on a fatal error. + noflushoncommit(*) flushoncommit The 'flushoncommit' mount option forces any data dirtied by a write in a prior transaction to commit as part of the current commit. This makes diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index fa9c698..c511239 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -324,7 +324,7 @@ enum { Opt_check_integrity, Opt_check_integrity_including_extent_data, Opt_check_integrity_print_mask, Opt_fatal_errors, Opt_rescan_uuid_tree, Opt_commit_interval, Opt_barrier, Opt_nodefrag, Opt_nocheck_integrity, - Opt_nodiscard, Opt_noenospc_debug, + Opt_nodiscard, Opt_noenospc_debug, Opt_noflushoncommit, Opt_err, }; @@ -350,6 +350,7 @@ static match_table_t tokens = { {Opt_noacl, "noacl"}, {Opt_notreelog, "notreelog"}, {Opt_flushoncommit, "flushoncommit"}, + {Opt_noflushoncommit, "noflushoncommit"}, {Opt_ratio, "metadata_ratio=%d"}, {Opt_discard, "discard"}, {Opt_nodiscard, "nodiscard"}, @@ -563,6 +564,11 @@ int btrfs_parse_options(struct btrfs_root *root, char *options) btrfs_info(root->fs_info, "turning on flush-on-commit"); btrfs_set_opt(info->mount_opt, FLUSHONCOMMIT); break; + case Opt_noflushoncommit: + if (btrfs_test_opt(root, FLUSHONCOMMIT)) + btrfs_info(root->fs_info, "turning off flush-on-commit"); + btrfs_clear_opt(info->mount_opt, FLUSHONCOMMIT); + break; case Opt_ratio: ret = match_int(&args[0], &intarg); if (ret) { -- 1.8.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 04/11] btrfs: Add nodiscard mount option.
Add nodiscard mount option to disable discard with remount option. Signed-off-by: Qu Wenruo --- changelog: v2: Add nodiscard mount option. --- Documentation/filesystems/btrfs.txt | 7 +-- fs/btrfs/super.c| 5 + 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt index aab54e9..344e67f 100644 --- a/Documentation/filesystems/btrfs.txt +++ b/Documentation/filesystems/btrfs.txt @@ -101,9 +101,12 @@ Options with (*) are default options and will not show in the mount options. can be avoided. Especially useful when trying to mount a multi-device setup as root. May be specified multiple times for multiple devices. + nodiscard(*) discard - Issue frequent commands to let the block device reclaim space freed by - the filesystem. This is useful for SSD devices, thinly provisioned + Disable/enable discard mount option. + Discard issues frequent commands to let the block device reclaim space + freed by the filesystem. + This is useful for SSD devices, thinly provisioned LUNs and virtual machine images, but may have a significant performance impact. (The fstrim command is also available to initiate batch trims from userspace). diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index b408d05..3ab11d4 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -324,6 +324,7 @@ enum { Opt_check_integrity, Opt_check_integrity_including_extent_data, Opt_check_integrity_print_mask, Opt_fatal_errors, Opt_rescan_uuid_tree, Opt_commit_interval, Opt_barrier, Opt_nodefrag, Opt_nocheck_integrity, + Opt_nodiscard, Opt_err, }; @@ -351,6 +352,7 @@ static match_table_t tokens = { {Opt_flushoncommit, "flushoncommit"}, {Opt_ratio, "metadata_ratio=%d"}, {Opt_discard, "discard"}, + {Opt_nodiscard, "nodiscard"}, {Opt_space_cache, "space_cache"}, {Opt_clear_cache, "clear_cache"}, {Opt_user_subvol_rm_allowed, "user_subvol_rm_allowed"}, @@ -576,6 +578,9 @@ int btrfs_parse_options(struct btrfs_root *root, char *options) case Opt_discard: btrfs_set_opt(info->mount_opt, DISCARD); break; + case Opt_nodiscard: + btrfs_clear_opt(info->mount_opt, DISCARD); + break; case Opt_space_cache: btrfs_set_opt(info->mount_opt, SPACE_CACHE); break; -- 1.8.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 11/11] btrfs: Add treelog mount option.
Add treelog mount option to enable tree log with remount option. Signed-off-by: Qu Wenruo --- changelog: v2: Add treelog mount option. --- Documentation/filesystems/btrfs.txt | 3 ++- fs/btrfs/super.c| 8 +++- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt index 480eeda..96a4fbd 100644 --- a/Documentation/filesystems/btrfs.txt +++ b/Documentation/filesystems/btrfs.txt @@ -169,8 +169,9 @@ Options with (*) are default options and will not show in the mount options. Enable/disable data checksumming for newly created files. Datasum implies datacow. + treelog(*) notreelog - Disable the tree logging used for fsync and O_SYNC writes. + Enable/disable the tree logging used for fsync and O_SYNC writes. recovery Enable autorecovery attempts if a bad tree root is found at mount time. diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index 01ae900..8efabee 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -325,7 +325,7 @@ enum { Opt_check_integrity_print_mask, Opt_fatal_errors, Opt_rescan_uuid_tree, Opt_commit_interval, Opt_barrier, Opt_nodefrag, Opt_nocheck_integrity, Opt_nodiscard, Opt_noenospc_debug, Opt_noflushoncommit, - Opt_noinode_cache, Opt_acl, Opt_datacow, Opt_datasum, + Opt_noinode_cache, Opt_acl, Opt_datacow, Opt_datasum, Opt_treelog, Opt_err, }; @@ -353,6 +353,7 @@ static match_table_t tokens = { {Opt_acl, "acl"}, {Opt_noacl, "noacl"}, {Opt_notreelog, "notreelog"}, + {Opt_treelog, "treelog"}, {Opt_flushoncommit, "flushoncommit"}, {Opt_noflushoncommit, "noflushoncommit"}, {Opt_ratio, "metadata_ratio=%d"}, @@ -581,6 +582,11 @@ int btrfs_parse_options(struct btrfs_root *root, char *options) btrfs_info(root->fs_info, "disabling tree log"); btrfs_set_opt(info->mount_opt, NOTREELOG); break; + case Opt_treelog: + if (btrfs_test_opt(root, NOTREELOG)) + btrfs_info(root->fs_info, "enabling tree log"); + btrfs_clear_opt(info->mount_opt, NOTREELOG); + break; case Opt_flushoncommit: btrfs_info(root->fs_info, "turning on flush-on-commit"); btrfs_set_opt(info->mount_opt, FLUSHONCOMMIT); -- 1.8.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/11] btrfs: Add nocheck_int mount option.
Add nocheck_int mount option to disable integrity check with remount option. Signed-off-by: Qu Wenruo --- changelog: v2: add nocheck_int mount option --- Documentation/filesystems/btrfs.txt | 3 +++ fs/btrfs/super.c| 15 ++- 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt index 65e885f..aab54e9 100644 --- a/Documentation/filesystems/btrfs.txt +++ b/Documentation/filesystems/btrfs.txt @@ -53,6 +53,7 @@ Options with (*) are default options and will not show in the mount options. them up for the defrag process. Works best for small files; Not well suited for large database workloads. + nocheck_int(*) check_int check_int_data check_int_print_mask= @@ -70,6 +71,8 @@ Options with (*) are default options and will not show in the mount options. as defined in fs/btrfs/check-integrity.c, to control the integrity checker module behavior. + nocheck_int disables all the debug options above. + See comments at the top of fs/btrfs/check-integrity.c for more info. commit= diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index c65f696..b408d05 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -323,7 +323,7 @@ enum { Opt_no_space_cache, Opt_recovery, Opt_skip_balance, Opt_check_integrity, Opt_check_integrity_including_extent_data, Opt_check_integrity_print_mask, Opt_fatal_errors, Opt_rescan_uuid_tree, - Opt_commit_interval, Opt_barrier, Opt_nodefrag, + Opt_commit_interval, Opt_barrier, Opt_nodefrag, Opt_nocheck_integrity, Opt_err, }; @@ -363,6 +363,7 @@ static match_table_t tokens = { {Opt_recovery, "recovery"}, {Opt_skip_balance, "skip_balance"}, {Opt_check_integrity, "check_int"}, + {Opt_nocheck_integrity, "nocheck_int"}, {Opt_check_integrity_including_extent_data, "check_int_data"}, {Opt_check_integrity_print_mask, "check_int_print_mask=%d"}, {Opt_rescan_uuid_tree, "rescan_uuid_tree"}, @@ -616,6 +617,17 @@ int btrfs_parse_options(struct btrfs_root *root, char *options) btrfs_set_opt(info->mount_opt, SKIP_BALANCE); break; #ifdef CONFIG_BTRFS_FS_CHECK_INTEGRITY + case Opt_nocheck_integrity: + if (btrfs_test_opt(root, CHECK_INTEGRITY) || + btrfs_test_opt(root, + CHECK_INTEGRITY_INCLUDING_EXTENT_DATA) || + info->check_integrity_print_mask != 0) + btrfs_info(root->fs_info, "disabling any integrity check"); + btrfs_clear_opt(info->mount_opt, CHECK_INTEGRITY); + btrfs_clear_opt(info->mount_opt, + CHECK_INTEGRITY_INCLUDING_EXTENT_DATA); + info->check_integrity_print_mask = 0; + break; case Opt_check_integrity_including_extent_data: btrfs_info(root->fs_info, "enabling check integrity including extent data"); @@ -641,6 +653,7 @@ int btrfs_parse_options(struct btrfs_root *root, char *options) } break; #else + case Opt_nocheck_integrity: case Opt_check_integrity_including_extent_data: case Opt_check_integrity: case Opt_check_integrity_print_mask: -- 1.8.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/11] btrfs: Add acl mount option.
Add acl mount option to enable acl with remount option. Signed-off-by: Qu Wenruo --- changelog: v2: Add acl mount option. --- Documentation/filesystems/btrfs.txt | 3 ++- fs/btrfs/super.c| 6 +- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt index ffb40f3..6f2de1b 100644 --- a/Documentation/filesystems/btrfs.txt +++ b/Documentation/filesystems/btrfs.txt @@ -146,8 +146,9 @@ Options with (*) are default options and will not show in the mount options. Specify that 1 metadata chunk should be allocated after every data chunks. Off by default. + acl(*) noacl - Disable support for Posix Access Control Lists (ACLs). See the + Enable/disable support for Posix Access Control Lists (ACLs). See the acl(5) manual page for more information about ACLs. barrier(*) diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index 16da3d1..a5c25fd 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -325,7 +325,7 @@ enum { Opt_check_integrity_print_mask, Opt_fatal_errors, Opt_rescan_uuid_tree, Opt_commit_interval, Opt_barrier, Opt_nodefrag, Opt_nocheck_integrity, Opt_nodiscard, Opt_noenospc_debug, Opt_noflushoncommit, - Opt_noinode_cache, + Opt_noinode_cache, Opt_acl, Opt_err, }; @@ -348,6 +348,7 @@ static match_table_t tokens = { {Opt_ssd, "ssd"}, {Opt_ssd_spread, "ssd_spread"}, {Opt_nossd, "nossd"}, + {Opt_acl, "acl"}, {Opt_noacl, "noacl"}, {Opt_notreelog, "notreelog"}, {Opt_flushoncommit, "flushoncommit"}, @@ -555,6 +556,9 @@ int btrfs_parse_options(struct btrfs_root *root, char *options) goto out; } break; + case Opt_acl: + root->fs_info->sb->s_flags |= MS_POSIXACL; + break; case Opt_noacl: root->fs_info->sb->s_flags &= ~MS_POSIXACL; break; -- 1.8.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 09/11] btrfs: Add datacow mount option.
Add datacow mount option to enable copy-on-write with remount option. Signed-off-by: Qu Wenruo --- changelog: v2: Add datacow mount option. --- Documentation/filesystems/btrfs.txt | 5 +++-- fs/btrfs/super.c| 8 +++- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt index 6f2de1b..48c1833 100644 --- a/Documentation/filesystems/btrfs.txt +++ b/Documentation/filesystems/btrfs.txt @@ -159,9 +159,10 @@ Options with (*) are default options and will not show in the mount options. (non-battery-backed) write-back cache, this option will lead to filesystem corruption on a system crash or power loss. + datacow(*) nodatacow - Disable data copy-on-write for newly created files. Implies nodatasum, - and disables all compression. + Enable/disable data copy-on-write for newly created files. + Nodatacow implies nodatasum, and disables all compression. nodatasum Disable data checksumming for newly created files. diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index a5c25fd..cb4c90d 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -325,7 +325,7 @@ enum { Opt_check_integrity_print_mask, Opt_fatal_errors, Opt_rescan_uuid_tree, Opt_commit_interval, Opt_barrier, Opt_nodefrag, Opt_nocheck_integrity, Opt_nodiscard, Opt_noenospc_debug, Opt_noflushoncommit, - Opt_noinode_cache, Opt_acl, + Opt_noinode_cache, Opt_acl, Opt_datacow, Opt_err, }; @@ -336,6 +336,7 @@ static match_table_t tokens = { {Opt_device, "device=%s"}, {Opt_nodatasum, "nodatasum"}, {Opt_nodatacow, "nodatacow"}, + {Opt_datacow, "datacow"}, {Opt_nobarrier, "nobarrier"}, {Opt_barrier, "barrier"}, {Opt_max_inline, "max_inline=%s"}, @@ -449,6 +450,11 @@ int btrfs_parse_options(struct btrfs_root *root, char *options) btrfs_set_opt(info->mount_opt, NODATACOW); btrfs_set_opt(info->mount_opt, NODATASUM); break; + case Opt_datacow: + if (btrfs_test_opt(root, NODATACOW)) + btrfs_info(root->fs_info, "setting datacow"); + btrfs_clear_opt(info->mount_opt, NODATACOW); + break; case Opt_compress_force: case Opt_compress_force_type: compress_force = true; -- 1.8.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/11] btrfs: Add noinode_cache mount option.
Add noinode_cache mount option to disable inode map cache with remount option. Signed-off-by: Qu Wenruo --- changelog: v2: Add noinode_cache mount option. --- Documentation/filesystems/btrfs.txt | 6 -- fs/btrfs/super.c| 7 +++ 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt index 516ed65..ffb40f3 100644 --- a/Documentation/filesystems/btrfs.txt +++ b/Documentation/filesystems/btrfs.txt @@ -129,9 +129,11 @@ Options with (*) are default options and will not show in the mount options. operations). This was previously the behavior only when a snapshot is created. + noinode_cache(*) inode_cache - Enable free inode number caching. Defaults to off due to an overflow - problem when the free space crcs don't fit inside a single page. + Disable/enable free inode number caching. + Defaults to off due to an overflow problem when the free space crcs + don't fit inside a single page. max_inline= Specify the maximum amount of space, in bytes, that can be inlined in diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index c511239..16da3d1 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -325,6 +325,7 @@ enum { Opt_check_integrity_print_mask, Opt_fatal_errors, Opt_rescan_uuid_tree, Opt_commit_interval, Opt_barrier, Opt_nodefrag, Opt_nocheck_integrity, Opt_nodiscard, Opt_noenospc_debug, Opt_noflushoncommit, + Opt_noinode_cache, Opt_err, }; @@ -363,6 +364,7 @@ static match_table_t tokens = { {Opt_defrag, "autodefrag"}, {Opt_nodefrag, "noautodefrag"}, {Opt_inode_cache, "inode_cache"}, + {Opt_noinode_cache, "noinode_cache"}, {Opt_no_space_cache, "nospace_cache"}, {Opt_recovery, "recovery"}, {Opt_skip_balance, "skip_balance"}, @@ -602,6 +604,11 @@ int btrfs_parse_options(struct btrfs_root *root, char *options) btrfs_info(root->fs_info, "enabling inode map caching"); btrfs_set_opt(info->mount_opt, INODE_MAP_CACHE); break; + case Opt_noinode_cache: + if (btrfs_test_opt(root, INODE_MAP_CACHE)) + btrfs_info(root->fs_info, "disabling inode map caching"); + btrfs_clear_opt(info->mount_opt, INODE_MAP_CACHE); + break; case Opt_clear_cache: btrfs_info(root->fs_info, "force clearing of disk cache"); btrfs_set_opt(info->mount_opt, CLEAR_CACHE); -- 1.8.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html