Re: btrfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Christoph Anton Mitterer posted on Sun, 05 Jun 2016 23:31:57 +0200 as
excerpted:

>> > Wasn't it said, that autodefrag performs bad for anything larger than
>> > ~1G?
>> 
>>    I don't recall ever seeing someone saying that. Of course, I may
>> have forgotten seeing it...
> I think it was mentioned below this thread:
> http://thread.gmane.org/gmane.comp.file-systems.btrfs/50444/focus=50586
> and also implied here:
> http://article.gmane.org/gmane.comp.file-systems.btrfs/51399/match=autodefrag+large+files

Yes.

I was rather surprised to see Hugo say he doesn't recall seeing anyone
state that autodefrag performs poorly on large (from half gig) files, and
that its primary recommended use is for smaller database files such as the
typical quarter-gig or smaller sqlite files created by firefox and various
mail clients (thunderbird, evolution).  Because I've both seen and
repeated that many times, myself, and indeed, the wiki's mount options
page used to say effectively that.

And actually, looking at the history of the page, it was Hugo that deleted
the wording to the effect that autodefrag didn't work well on large
database or VM files..

https://btrfs.wiki.kernel.org/index.php?title=Mount_options&diff=29268&oldid=28191

So if he doesn't remember it...

But perhaps Hugo read it as manual defrag, not autodefrag, as I don't
remember manual defrag ever being associated with that problem (tho it did
and does still have the reflinks/snapshots problem, but that's a totally
different issue).


Meanwhile, it's news to me that autodefrag doesn't have that problem any
longer...





-- 
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux