Jason Russell
2013-Jul-20 15:15 UTC
Lots of harddrive chatter on after booting with btrfs on root (slow boot)
Hi, I''ve been using btrfs for my root partition for about a month on archlinux and recently Ive started using the i3 window manager and starting X manually and I now boot to run level 3 (multi-user.target for systemd) and Ive noticed that booting archlinux on a btrfs root, there is a lot off hdd chatter after the login prompts are displayed, which doesnt happen with ext4 on root, so I have done some testing and comparisons. I have stripped down two arch installs, one with btrfs root and one with ext4, (same laptop, same hdd) I removed all packages except for the base group. On the btrfs root, there is about +- 15 seconds of hdd chatter and it takes a long time to log in from the prompts, with the ext4 root, the computer is silent after the prompts pop up and login is almost instant. The prompts of the two installs pop up at more or less the same time (+- 3 seconds) but the login on the btrfs root takes muuch longer than the ext4. Ive also noted that this excessive hdd chatter does not occur immediately after a fresh format with arch on btrfs root. Ive made some deductions/assumptions: This only seems to occur with btrfs roots. This only happens after some number of reboots OR after the partition fills up a little bit. Im pretty sure of ruled out everything except for the filesystem. I have just done two clean installs to more thoroughly compare ext4 and btrfs roots. So far no excessive hdd chatter from btrfs. I have also seen what I have described on two other computers (different hardware entirely) where there is lots of hdd chatter from btrfs root, and nothing from ext4. Here are two threads: https://bbs.archlinux.org/viewtopic.php?pid=1117932 https://bbs.archlinux.org/viewtopic.php?pid=1301684 Any ideas? Thanks, -- Jason Russell -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
George Mitchell
2013-Jul-20 15:52 UTC
Re: Lots of harddrive chatter on after booting with btrfs on root (slow boot)
Sounds to me like a fragmentation issue. On 07/20/2013 08:15 AM, Jason Russell wrote:> Hi, > > I''ve been using btrfs for my root partition for about a month on > archlinux and recently Ive started using the i3 window manager and > starting X manually and I now boot to run level 3 (multi-user.target > for systemd) and Ive noticed that booting archlinux on a btrfs root, > there is a lot off hdd chatter after the login prompts are displayed, > which doesnt happen with ext4 on root, so I have done some testing and > comparisons. > > I have stripped down two arch installs, one with btrfs root and one > with ext4, (same laptop, same hdd) I removed all packages except for > the base group. On the btrfs root, there is about +- 15 seconds of hdd > chatter and it takes a long time to log in from the prompts, with the > ext4 root, the computer is silent after the prompts pop up and login > is almost instant. The prompts of the two installs pop up at more or > less the same time (+- 3 seconds) but the login on the btrfs root > takes muuch longer than the ext4. > > Ive also noted that this excessive hdd chatter does not occur > immediately after a fresh format with arch on btrfs root. > > Ive made some deductions/assumptions: > This only seems to occur with btrfs roots. > This only happens after some number of reboots OR after the partition > fills up a little bit. > Im pretty sure of ruled out everything except for the filesystem. > > > I have just done two clean installs to more thoroughly compare ext4 > and btrfs roots. So far no excessive hdd chatter from btrfs. > > I have also seen what I have described on two other computers > (different hardware entirely) where there is lots of hdd chatter from > btrfs root, and nothing from ext4. > > Here are two threads: > https://bbs.archlinux.org/viewtopic.php?pid=1117932 > https://bbs.archlinux.org/viewtopic.php?pid=1301684 > > Any ideas? > > Thanks, > > -- > Jason Russell > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > >-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Lukas Martini
2013-Jul-20 22:14 UTC
Re: Lots of harddrive chatter on after booting with btrfs on root (slow boot)
Hey, I wouldn''t neccessarily say this is a btrfs specific problem. I''m experiencing the same issues in a very similar setup (Also using Arch Linux, booting to multi-user.target with systemd and starting X manually, also using the i3 window manager) and I''m using ext4 for the root partition. Best, Lukas On 07/20/2013 05:15 PM, Jason Russell wrote:> Hi, > > I''ve been using btrfs for my root partition for about a month on > archlinux and recently Ive started using the i3 window manager and > starting X manually and I now boot to run level 3 (multi-user.target > for systemd) and Ive noticed that booting archlinux on a btrfs root, > there is a lot off hdd chatter after the login prompts are displayed, > which doesnt happen with ext4 on root, so I have done some testing and > comparisons. > > I have stripped down two arch installs, one with btrfs root and one > with ext4, (same laptop, same hdd) I removed all packages except for > the base group. On the btrfs root, there is about +- 15 seconds of hdd > chatter and it takes a long time to log in from the prompts, with the > ext4 root, the computer is silent after the prompts pop up and login > is almost instant. The prompts of the two installs pop up at more or > less the same time (+- 3 seconds) but the login on the btrfs root > takes muuch longer than the ext4. > > Ive also noted that this excessive hdd chatter does not occur > immediately after a fresh format with arch on btrfs root. > > Ive made some deductions/assumptions: > This only seems to occur with btrfs roots. > This only happens after some number of reboots OR after the partition > fills up a little bit. > Im pretty sure of ruled out everything except for the filesystem. > > > I have just done two clean installs to more thoroughly compare ext4 > and btrfs roots. So far no excessive hdd chatter from btrfs. > > I have also seen what I have described on two other computers > (different hardware entirely) where there is lots of hdd chatter from > btrfs root, and nothing from ext4. > > Here are two threads: > https://bbs.archlinux.org/viewtopic.php?pid=1117932 > https://bbs.archlinux.org/viewtopic.php?pid=1301684 > > Any ideas? > > Thanks, > > -- > Jason Russell > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Gabriel de Perthuis
2013-Jul-20 22:47 UTC
Re: Lots of harddrive chatter on after booting with btrfs on root (slow boot)
On Sat, 20 Jul 2013 17:15:50 +0200, Jason Russell wrote:> Ive also noted that this excessive hdd chatter does not occur > immediately after a fresh format with arch on btrfs root. > > Ive made some deductions/assumptions: > This only seems to occur with btrfs roots. > This only happens after some number of reboots OR after the partition > fills up a little bit. > Im pretty sure of ruled out everything except for the filesystem.In my experience (as of 3.8 or so), Btrfs performance degrades on a filled-up filesystem, even a comparatively new one. Various background workers start to eat io according to atop.> I have just done two clean installs to more thoroughly compare ext4 > and btrfs roots. So far no excessive hdd chatter from btrfs. > > I have also seen what I have described on two other computers > (different hardware entirely) where there is lots of hdd chatter from > btrfs root, and nothing from ext4. > > Here are two threads: > https://bbs.archlinux.org/viewtopic.php?pid=1117932 > https://bbs.archlinux.org/viewtopic.php?pid=1301684-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Duncan
2013-Jul-21 10:38 UTC
Re: Lots of harddrive chatter on after booting with btrfs on root (slow boot)
Gabriel de Perthuis posted on Sat, 20 Jul 2013 22:47:46 +0000 as excerpted:> On Sat, 20 Jul 2013 17:15:50 +0200, Jason Russell wrote: >> Ive also noted that this excessive hdd chatter does not occur >> immediately after a fresh format with arch on btrfs root. >> >> Ive made some deductions/assumptions: >> This only seems to occur with btrfs roots. >> This only happens after some number of reboots OR after the partition >> fills up a little bit. >> Im pretty sure of ruled out everything except for the filesystem. > > In my experience (as of 3.8 or so), Btrfs performance degrades on a > filled-up filesystem, even a comparatively new one. Various background > workers start to eat io according to atop.I''d say it''s likely fragmentation as George M mentioned, but that (as with most filesystems to some degree, but COW filesystems such as btrfs are often worse) performance (including fragmentation) tends to get worse when the filesystem''s almost full, as Gabriel mentions here. I do remember reading a comment on a btrfs commit to the effect that when the filesystem''s almost full, it stops trying to allocate nice large extents and takes the space wherever it can get it. Once that happens, especially with a COW filesystem such as btrfs, if you''re doing any regular sort of writing at all, you **WILL** get **BAD** fragmentation. What I''d suggest is to turn on the btrfs autodefrag mount option, and to do it *BEFORE* you start installing stuff on the filesystem. I believe it''s a known issue that a number of distro installers (what arch does I''m not sure) tend to fragment their files pretty badly right off the bat if you let them. This would happen if they write data into an existing file, perhaps because they install a package and then customize the config files, or if they don''t write whole files at once. And a lot of btrfs installs don''t turn on the autodefrag option when they do thet first auto- mount to install stuff. So a lot of folks end up with a heavily fragmented brand new installation, and if they try turning on autodefrag at that point, it slows the system way down for several boots, because it keeps finding fragmented files, so they turn it off again, likely just as they''d otherwise start to actually see the benefits. But either ensuring autodefrag is on starting from an empty filesystem, or if the installer doesn''t make that easy, installing to a temp location and then preparing the final btrfs location, mounting it with autodefrag, and copying all the files over, in either case ensuring that no files are written to the filesystem before autodefrag is turned on, should help. Then, do remember that btrfs is still under heavy development, so keep good backups if you choose to test it out. Also, while I think they''re actually beginning to work thru them now, until quite recently, btrfs had serious no-space issues when the filesystem started to fill up. So you probably want to keep more freespace on btrfs than you would on ext4, just to be on the safe side. Also, in keeping with the development nature of the filesystem, run at least the latest stable kernel (if not the development kernels if not btrfs-next), as the latest kernels really do have fixes that previous versions are missing. Finally, if you haven''t yet, take a look at the btrfs wiki, as it covers a lot of questions and issues you may have. https://btrfs.wiki.kernel.org/ -- 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Jul 21, 2013, at 4:38 AM, Duncan <1i5t5.duncan@cox.net> wrote:> > What I''d suggest is to turn on the btrfs autodefrag mount option, and to > do it *BEFORE* you start installing stuff on the filesystem.Is there a good reason why autodefrag is not a default mount option?> I believe > it''s a known issue that a number of distro installers (what arch does I''m > not sure) tend to fragment their files pretty badly right off the bat if > you let them. This would happen if they write data into an existing > file, perhaps because they install a package and then customize the config > files, or if they don''t write whole files at once. And a lot of btrfs > installs don''t turn on the autodefrag option when they do thet first auto- > mount to install stuff.Some installer teams are understandably reluctant to use non-default mount options. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Chris Murphy posted on Sun, 21 Jul 2013 10:20:48 -0600 as excerpted:> On Jul 21, 2013, at 4:38 AM, Duncan <1i5t5.duncan@cox.net> wrote: >> >> What I''d suggest is to turn on the btrfs autodefrag mount option, and >> to do it *BEFORE* you start installing stuff on the filesystem. > > Is there a good reason why autodefrag is not a default mount option?Well, there''s the obvious, that btrfs is still in development, lacking such things as the ability to set such options by default using btrfs- tune, and likely with the question of what should be the defaults still unresolved for many cases. Autodefrag can also negatively affect performance especially if it''s not on from the beginning, AND at least at one point earlier in btrfs evolution (I''m not sure if it''s fixed now or not), the performance for very large and often written into files such as virtual-machine images and large databases was bad, since it could mean constantly rewriting entire large files instead of just the smaller changing pieces of them, thereby being a performance killer for that type of job load.>> I believe >> it''s a known issue that a number of distro installers (what arch does >> I''m not sure) tend to fragment their files pretty badly right off the >> bat if you let them. This would happen if they write data into an >> existing file, perhaps because they install a package and then >> customize the config files, or if they don''t write whole files at once. >> And a lot of btrfs installs don''t turn on the autodefrag option when >> they do thet first auto- >> mount to install stuff. > > Some installer teams are understandably reluctant to use non-default > mount options.It''s worth keeping in mind the bigger picture, tho, that in the case of btrfs they''re using a still in development filesystem (even if it''s not the default, the fact that so few people come here unaware of the wiki or btrfs status as a development filesystem IMO indicates that installers aren''t including the warnings about making such even non-default choices that they arguably should be including) where all recommendations are to be ready for loss of data should it occur, as it''s a definitely more likely possibility than it should be with a stable filesystem. With that in mind, playing with non-default mount options seems rather trivial by comparison. Still, the previously mentioned constantly written large vm/db file use- case is a big one these days, and with the general purpose installation often not having dedicated partitions for such things (btrfs subvolumes don''t yet allow per-subvolume setting of such options)... But for the generally much different use-case of a system volume where all the system binaries and config is stored, autodefrag makes a lot of sense to enable by default. Or installers could simply be better about not writing into existing files in the installation in the first place, so people could turn it on right after installation and not have to worry about existing fragmentation. But... installing to btrfs is really a reasonably new situation, and I''d guess "best practices" are still evolving just as the filesystem itself is. -- 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
George Mitchell
2013-Jul-21 23:44 UTC
Re: autodefrag by default, was: Lots of harddrive chatter
On 07/21/2013 03:01 PM, Duncan wrote:> Chris Murphy posted on Sun, 21 Jul 2013 10:20:48 -0600 as excerpted: > >> On Jul 21, 2013, at 4:38 AM, Duncan <1i5t5.duncan@cox.net> wrote: >>> What I''d suggest is to turn on the btrfs autodefrag mount option, and >>> to do it *BEFORE* you start installing stuff on the filesystem. >> Is there a good reason why autodefrag is not a default mount option? > Well, there''s the obvious, that btrfs is still in development, lacking > such things as the ability to set such options by default using btrfs- > tune, and likely with the question of what should be the defaults still > unresolved for many cases. > > Autodefrag can also negatively affect performance especially if it''s not > on from the beginning, AND at least at one point earlier in btrfs > evolution (I''m not sure if it''s fixed now or not), the performance for > very large and often written into files such as virtual-machine images > and large databases was bad, since it could mean constantly rewriting > entire large files instead of just the smaller changing pieces of them, > thereby being a performance killer for that type of job load. > >>> I believe >>> it''s a known issue that a number of distro installers (what arch does >>> I''m not sure) tend to fragment their files pretty badly right off the >>> bat if you let them. This would happen if they write data into an >>> existing file, perhaps because they install a package and then >>> customize the config files, or if they don''t write whole files at once. >>> And a lot of btrfs installs don''t turn on the autodefrag option when >>> they do thet first auto- >>> mount to install stuff. >> Some installer teams are understandably reluctant to use non-default >> mount options. > It''s worth keeping in mind the bigger picture, tho, that in the case of > btrfs they''re using a still in development filesystem (even if it''s not > the default, the fact that so few people come here unaware of the wiki or > btrfs status as a development filesystem IMO indicates that installers > aren''t including the warnings about making such even non-default choices > that they arguably should be including) where all recommendations are to > be ready for loss of data should it occur, as it''s a definitely more > likely possibility than it should be with a stable filesystem. With that > in mind, playing with non-default mount options seems rather trivial by > comparison. > > Still, the previously mentioned constantly written large vm/db file use- > case is a big one these days, and with the general purpose installation > often not having dedicated partitions for such things (btrfs subvolumes > don''t yet allow per-subvolume setting of such options)... > > But for the generally much different use-case of a system volume where > all the system binaries and config is stored, autodefrag makes a lot of > sense to enable by default. > > Or installers could simply be better about not writing into existing > files in the installation in the first place, so people could turn it on > right after installation and not have to worry about existing > fragmentation. But... installing to btrfs is really a reasonably new > situation, and I''d guess "best practices" are still evolving just as the > filesystem itself is. >Duncan, First of all, thanks so much for the great explanation. It really answers a LOT of questions as to the whole fragmentation issue and covers a lot of bases. And I totally agree with some of your thoughts regarding the still beta status of btrfs and its effect on support and documentation, etc. But I think the only unanswered question for me at this point is whether complete defragmentation is even possible using auto-defrag. Unless auto-defrag can work around the in-use file issue, that could be a problem since some heavily used system files are open virtually all the time the system is up and running. Has this issue been investigated and if so are there any system files that don''t get defragmented that matter? Or is this a non-issue in that any constantly in use system files don''t really matter anyway? That is really the only question I have before moving away from my current offline approach to the auto-defrag mount option for system filesystems (/, /boot, /usr, /opt, /var, etc). -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Shridhar Daithankar
2013-Jul-22 03:37 UTC
Re: autodefrag by default, was: Lots of harddrive chatter
On Sunday, July 21, 2013 04:44:09 PM George Mitchell wrote:> Unless auto-defrag can work around the > in-use file issue, that could be a problem since some heavily used > system files are open virtually all the time the system is up and > running. Has this issue been investigated and if so are there any > system files that don''t get defragmented that matter? Or is this a > non-issue in that any constantly in use system files don''t really matter > anyway? That is really the only question I have before moving away from > my current offline approach to the auto-defrag mount option for system > filesystems (/, /boot, /usr, /opt, /var, etc).AFAIK, defragmentation is proportional to amount of writes to a file or direcotries. system files typically are installed once and never rewritten in place, so they should not be much fragmented to begin with. now their directory objects, is a different story and so is things like systemd journal, log files, or database files. -- Regards Shridhar -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
George Mitchell
2013-Jul-22 03:53 UTC
Re: autodefrag by default, was: Lots of harddrive chatter
On 07/21/2013 08:37 PM, Shridhar Daithankar wrote:> On Sunday, July 21, 2013 04:44:09 PM George Mitchell wrote: >> Unless auto-defrag can work around the >> in-use file issue, that could be a problem since some heavily used >> system files are open virtually all the time the system is up and >> running. Has this issue been investigated and if so are there any >> system files that don''t get defragmented that matter? Or is this a >> non-issue in that any constantly in use system files don''t really matter >> anyway? That is really the only question I have before moving away from >> my current offline approach to the auto-defrag mount option for system >> filesystems (/, /boot, /usr, /opt, /var, etc). > AFAIK, defragmentation is proportional to amount of writes to a file or > direcotries. > > system files typically are installed once and never rewritten in place, so > they should not be much fragmented to begin with. > > now their directory objects, is a different story and so is things like > systemd journal, log files, or database files.Never rewritten in place? I wouldn''t go that far. In the case of many distros there is a continual flow of updates which results in some degree of data churning throughout the system filesystems. Just a kernel update, for example, can affect a rather large number of files and directories with new writes while application updates (KDE or even Gnome for example) can cause a large number of files to be rewritten in place. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Shridhar Daithankar
2013-Jul-22 04:11 UTC
Re: autodefrag by default, was: Lots of harddrive chatter
On Sunday, July 21, 2013 08:53:42 PM George Mitchell wrote:> > system files typically are installed once and never rewritten in place, so > > they should not be much fragmented to begin with. > > > > now their directory objects, is a different story and so is things like > > systemd journal, log files, or database files. > > Never rewritten in place? I wouldn''t go that far. In the case of many > distros there is a continual flow of updates which results in some > degree of data churning throughout the system filesystems. Just a kernel > update, for example, can affect a rather large number of files and > directories with new writes while application updates (KDE or even Gnome > for example) can cause a large number of files to be rewritten in place.While it is true that large number of files are changed with each update, most of the update delete the existing files and install new one. That does not lead to fragmentation of a file. Unless the packages are patching the files in place(AFAIK, even delta RPMs patch the RPM and not the individual files), it would not lead to the defragmentation that is problematic on btrfs. There are two types of defragmentations. first is where files are continually added/deleted to the file system, e.g. a mail server. IME btrfs handles that quite well. Another is where a file is constantly updated in place e.g. a postgresql/sqlite database. In the second case, COW nature of btrfs causes the defragmentation which directly affects the performance, at least on spinning hard disks. -- Regards Shridhar -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
George Mitchell posted on Sun, 21 Jul 2013 16:44:09 -0700 as excerpted:> But I think the only unanswered question for me at this point is whether > complete defragmentation is even possible using auto-defrag. Unless > auto-defrag can work around the in-use file issue, that could be a > problem since some heavily used system files are open virtually all the > time the system is up and running. Has this issue been investigated and > if so are there any system files that don''t get defragmented that > matter? Or is this a non-issue in that any constantly in use system > files don''t really matter anyway?I believe Shridnar has it right; writes into a file/directory are the big fragmentation issue for btrfs. But there''s one aspect he overlooked -- this is another reason I so strongly stress the autodefrag-from-newly- created-empty-filesystem-on point: for the general case, if autodefrag is on when the files are written in the first place, they won''t be fragmented when they''re loaded and the file is thus in-use, so there won''t be any need to defrag them when in-use. There''s two main forms of always-in-use files, executables/libraries etc that nay be memory-mapped, and database/vm-image files where the vm or database is always running. (And arguably, given a broad enough definition of database files, nearly anything else that would fall in this category including vm-images is already covered by that, so...) In the executables/libraries case, the files are generally NOT in-place rewritten, and installations/updates don''t tend to be a problem either. Unlike MS where in-use files (used to be? I''ve been off MS for years so don''t know whether this remains true on their current product) cannot/ could-not be replaced without a reboot, on Linux, the kernel allows unlinking and replacement of in-use files, with the references to previously existing file maintained in memory only; no actual storage- location overwrite allowed until there are no further runtime references to the old file. Sometime after you''ve done some in-use library/elf-file-executable package updates, try this. Look thru /proc/*/maps, where * is the PID of the process you''re investigating. (You''ll need to be root to look at processes running as other users.) This is a list of files that process has mapped. (It''s documented in the kernel documentation, see $KERNELDIR/ Documentation/filesystems/proc.txt and search for /proc/PID/maps.) On the right side is the pathname. What''s we''re interested in here, however, is what happens when one of those files is replaced. To the right of the pathname there will be a notation: "(deleted)". These are files that have been unlinked (deleted or replaced), with the kernel maintaining the reference to the old location even tho a file listing won''t show the old file any longer, until all existing runtime file references are terminated. There are actually helper-scripts available that will look thru /proc/PID/ maps and tell you which apps you need to restart to use the updated files. Another user of this unlink but keep the reference trick is certain media apps such as flash, that will download a file to a temporary location, load it and keep the open reference, then delete the file so it no longer appears in the filesystem. Among other things, this makes it more difficult to copy files some people seem to think the user shouldn''t be copying, since the only way to get to the file once it is unlinked is by somehow grabbing the open reference to it that the app still has. Coming back to the topic at hand, as a result of the above mechanism, updates aren''t normally rewritten actually in-place, normally allowing them to be written as a single unfragmented file, or if fragmented, autodefrag will notice and schedule a defragment for the defrag thread. With the exception of something like glibc, where the new library is put to work the next time something runs, that generally leaves time for a defragment if necessary, and ideally, it won''t be necessary since the file should have been written in one piece, without fragmentation (unless there''s so little space left the filesystem is in use what we can find mode and thus is no longer worried about fragmentation). VM images and database files are a rather different story, since they''re OFTEN rewritten in place. The btrfs autodefrag option should handle reasonably small database files such as firefox''s sqlite files without too much difficulty. However, there''s a warning on the wiki about performance issues with larger database files and VM images (I''d guess in the range of gigabytes). The issues /may/ have been solved by now but I''m not sure. However, it''s possible to mark such files (or more likely, the directory they''re in, since the marking should be done at creation in ordered to be effective, and files inherit from the directory so will get it at creation if the directory has it) NODATACOW, so they get updated in- place and thus don''t fragment any further on in-place writes. Yes, that''s individual handling, but we''re talking database/vm-image files in the gigabytes, so it''s not like /most/ people would be managing hundreds or thousands of them, and if they are, they should be scripting the handling anyway, and can just throw the nodatacow handling into the script. So as I said, ensure autodefrag is one from the new and empty filesystem state as it fills up, and with the exception of big database/vm-image files which can be handled separately, it should "just work", since you''ll be handling fragmentation routinely as it happens. -- 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html