On Thu, Sep 20, 2012 at 07:36:53AM +0800, ching wrote: > > >>> 2. AFAIK, "autodefrag" detects small random writes into files and > >>> queues them up for an automatic defrag process, so the filesystem will > >>> defragment itself while it's used. > >>> > >>> If the system reboot/crash/remount-ro, will the autodefrag process > >>> continue after resume? > >>> > > For reboot, autodefrag will be waited to finish during umounting btrfs. > > > > For crash and remount-ro, it won't resume since it is not that necessary and we're all > > COWed so that the data is ok. > > > > And autodefrag will only take effect when taking the 'autodefrag' mount option. > > > > thanks, > > liubo > > > > > > Can the loophole be fixed by tuning the autodefrag algorithm? e.g. > also queue up small extents detected during read operation for the > autodefrag process. Sounds interesting, though this would increase write load for a pure read but may improve fragmentation situation and is obviously done only on the first read. The write side of autodefrag could be extended to defrag also small extents that would fit into some threshold, not only newly written data. > Is there any io niceness control for autodefrag process too? it will > be nice if the idle class is used. No. Autodefrag will mark file data dirty and they'll be written back to the storage in the same way as any other write through the worker threads. > Actually, i try to write shell script to defrag entire FS monthy. but > i soon find out it is hard to keep track of progress across reboot and > avoid redefragging defragged file The defrag process will skip already deframented files (in the meaning of "defragmented" as it sees fit, implementation dependent currently, not exactly that the file has 1 extent). > For me, autodefrag is a killer feature. :) Yeah, it improves the inherent problem of fragmentation for a COW based filesystem. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
