Options for SSD - autodefrag etc?

I was wondering about whether using options like "autodefrag" and "inode_cache" on SSDs.

On one hand, one always hears that defragmentation of SSD is a no-no, does that apply to BTRFS's autodefrag? Also, just recently, I heard something similar about "inode_cache".

On the other hand, Arch BTRFS wiki recommends to use both options on SSDs
http://wiki.archlinux.org/index.php/Btrfs#Mount_options

So to clear things up, I ask at the source where people should know best.

Does using those options on SSDs gives any benefits and causes non-negligible increase in SSD wear?

KC posted on Thu, 23 Jan 2014 23:23:35 +0100 as excerpted:

inode_cache is not recommended for general use, tho it can make sense for use-cases such as busy maildir based email servers where there's a lot of small files being constantly written and erased. Additionally, since btrfs is not yet fully stable (tho with kernel 3.13 the kconfig warning for btrfs was officially decreased in severity), my thought is if it's disabled, that's one less feature I have to worry about bugs in, for my filesystems. =:^) So don't enable inode_cache unless you know you need it.

autodefrag is an interesting one, and I asked about it too when I was setting up my ssd-backed btrfs filesystems, so good question! =:^)

Yes, autodefrag does use up somewhat limited on SSD write cycles, and yes, there's no seek time to worry about on SSDs so fragmentation doesn't hurt as badly as it does on spinning rust.

There's still some cost to fragmentation, however -- each file fragment is an IOPS count on access, and while modern SSDs are rated pretty high IOPS, copy-on-write (COW) based filesystems like btrfs can heavily fragment "internally rewritten" (as opposed to written once and never changed, or new data always appended at the end like a log file or streaming media recording) files. We've seen worst-cases internal- rewritten files such as multi-gig VMs reported here, with 100K extents or more! That *WILL* eat up IOPS, even on SSDs, and there's other serious issues with that heavily fragmented a file as well, not least the additional chance of damage to it given all the work btrfs has to do tracking all those extents! But for that large a file, autodefrag isn't really the best option. See a couple paragraphs down for a better one for such large files.

There are several COW-triggered fragmentation worst-cases. Perhaps the most common one on a typical desktop is small database files such as the sqlite files used for firefox history, cookies, etc, and this is where the autodefrag mount option really shines and what it was designed for.

Larger internal-write files (say half a gig or bigger), particularly highly active ones where file updates may come fast enough rewriting the whole file slows things down, like big active database files, pre- allocated bittorrent download files, or multi-gig VM images, are a rather different problem, and autodefrag doesn't work as well with them. For these, the NOCOW file attribute (set with chattr +C, see the chattr manpage), which with btrfs must be set before data is written into the file, works rather better. The easiest way to set the attribute before the file is written into is to set it on the containing directory so new files created in it inherit the attribute automatically. So setup your database, VMs, or torrent client to use the same dir for everything, then set +C/NOCOW on that dir before the files are downloaded/created/copied- into-it/whatever. That way, rewrites happen in-place instead of creating a new extent every time some bit of the file changes.

Of course another alternative is to use an entirely separate filesystem for your big internal-write files, either something like ext4 that's not COW-based, or btrfs with the NODATACOW mount option set (tho you'd definitely not want to use that for a general purpose btrfs).

But back to autodefrag. It's also worth noting that actually doing the install with this option enabled can make a difference too, as apparently a number of popular distro installers trigger fragmentation during their work, leaving even brand new installations heavily fragmented if the install is to btrfs mounted without autodefrag.

One more note on fragmentation. filefrag doesn't yet understand btrfs compression, and reports each compression block (128 KiB IIRC) as a separate extent. So if you use compression (I use compress=lzo, here), don't be surprised to see larger files reported as several hundred extents, perhaps a few thousand on gigabyte sized files. If you're worried about it, (manually, btrfs fi defrag) defrag the file and see if the number of reported extents goes down significantly. If it does, the file was fragmented and defragmenting helped. If not, defragmenting didn't help.

Anyway, yes, I turned autodefrag on for my SSDs, here, but there are arguments to be made in either direction, so I can understand people choosing not to do that.

One not-btrfs specific mount option that's very useful for btrfs, particularly if you're using btrfs snapshotting features, SSD or not, is noatime. While admins have been disabling atime updates for years to get better performance and that's recommended in general unless you run mutt (with other than mbox files) or something else that requires it, given that the exclusive size of a snapshot is the size of the filesystem changes written between it and the previous snapshot, with atime updates on and not a lot of other writes, those atime updates can be a big part of the exclusive size of that snapshot! So disabling them means smaller and more efficient snapshots, particularly if there isn't that much other write activity going on either.

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

Hi Duncan,

Am Freitag, 24. Januar 2014, 06:54:31 schrieb Duncan:

Do you have numbers to back up that this gives any advantage?

I have it disabled and yet I have things like:

Oh, this is insane. This filefrags runs for over a minute already. And hogging on one core eating almost 100% of its processing power.

merkaba:/home/martin/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend> /usr/bin/time -v filefrag soprano-virtuoso.db

Wow, this still didn´t complete yet – even after 5 minutes.

Well I have some files with several ten thousands extent. But first, this is mounted with compress=lzo, so 128k is the largest extent size as far as I know, and second: I did manual btrfs filesystem defragment on files like those and and never ever perceived any noticable difference in performance.

Thus I just gave up on trying to defragment stuff on the SSD.

Well, now that command completed:

soprano-virtuoso.db: 93807 extents found
Command being timed: "filefrag soprano-virtuoso.db" User time (seconds): 0.00
System time (seconds): 338.77
Percent of CPU this job got: 98%
Elapsed (wall clock) time (h:mm:ss or m:ss): 5:42.81 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 520 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 181 Voluntary context switches: 9978 Involuntary context switches: 1216
Swaps: 0
File system inputs: 150160
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0

And this is really quite high. But… I think I have a more pressing issue with that BTRFS /home on an Intel SSD 320 and that is that it is almost full:

merkaba:~> LANG=C df -hT /home

Filesystem               Type   Size  Used Avail Use% Mounted on
/dev/mapper/merkaba-home btrfs  254G  241G  8.5G  97% /home

merkaba:~> btrfs filesystem show
[…]
Label: home uuid: […]
Total devices 1 FS bytes used 238.99GiB
devid 1 size 253.52GiB used 253.52GiB path /dev/mapper/merkaba-home

Btrfs v3.12

merkaba:~> btrfs filesystem df /home
Data, single: total=245.49GiB, used=237.07GiB
System, DUP: total=8.00MiB, used=48.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=4.00GiB, used=1.92GiB
Metadata, single: total=8.00MiB, used=0.00

Okay, I could probably get back 1,5 GiB on metadata, but whenever I tried a btrfs filesystem balance on any of the BTRFS filesystems on my SSD I usually got the following unpleasant result:

Halve of the performance. Like double boot times on / and such.

So I have the following thoughts:

1) I am not yet clear whether defragmenting files on SSD will really bring a benefit.

2) On my /home problem is more that it is almost full and free space appears to be highly fragmented. Long fstrim times speak tend to agree with it:

merkaba:~> /usr/bin/time fstrim -v /home
/home: 13494484992 bytes were trimmed
0.00user 12.64system 1:02.93elapsed 20%CPU (0avgtext+0avgdata 768maxresident)k 192inputs+0outputs (0major+243minor)pagefaults 0swaps

3) Turning autodefrag on might fragment free space even more.

4) I have no clear conclusion on what maintenance other than scrubbing might make sense for BTRFS filesystems on SSDs at all. Everything I tried either did not have any perceivable effect or made things worse.

Thus for SSD except for the scrubbing and the occasional fstrim I be done with it.

For harddisks I enable autodefrag.

But still for now this is only guess work. I don´t have much clue on BTRFS filesystems maintenance yet and I just remember the slogan on xfs.org wiki:

"Use the defaults."

With a cite of Donald Knuth:

"Premature optimization is the root of all evil."

http://xfs.org/index.php/XFS_FAQ#Q:_I_want_to_tune_my_XFS_filesystems_for_.3Csomething.3E

I would love to hear some more or less official words from BTRFS filesystem developers on that. But for know I think one of the best optimizations would be to complement that 300 GB Intel SSD 320 with a 512 GB Crucial m5 mSATA SSD or some Intel mSATA SSDs (but these cost twice as much), and make more free space on /home again. For criticial data regarding data safety and amount of accesses I could even use BTRFS RAID 1 then. All those MPEG3 and photos I could place on the bigger mSATA SSD. Granted a SSD is definately not needed for those, but it is just more silent. I never got how loud even a tiny 2,5 inch laptop drive is, unless I switched one external on while using this ThinkPad T520 with SSD. For the first time I heard the harddisk clearly. Thus I´d prefer a SSD anyway.

Still even with that highly full filesystem performance is pretty nice here. Except for some burts on btrfs-delalloc kernel threads once in a while. Especially when I fill it even a bit more. BTRFS has trouble finding free space on this partition. I saw this thread being active for half a minute without much happening on BTRFS. Thus I really think its good to get it at least to 20-30 GiB free again. Well I could still add about 13 GiB to it if I get rid of a 10 GiB volume for testing out SSD caching.

Ciao,

Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Martin Steigerwald posted on Sat, 25 Jan 2014 13:54:40 +0100 as excerpted:

Your post (like some of mine) reads like a stream of consciousness more than a well organized post, making it somewhat difficult to reply to (I guess I'm now experiencing the pain others sometimes mention when trying to reply to some of mine). However, I'll try...

I haven't done benchmarks, etc, nor do I have them at hand to quote, if that's what you're asking for. But of course I did say I understand the arguments made by both sides, and just gave the reasons why I made the choice I did, here.

What I /do/ have is the multiple post here on this list from people complaining about pathologic[1] performance issues due to large-internal- written-file fragmentation even on SSDs, particularly so when interacting with non-trivial numbers of snapshots as well. That's a case that at present simply Does. Not. Scale. Period!

Of course the multi-gig internal-rewritten-file case is better suited to the NOCOW extended attribute than to autodefrag, but anyway...

I don't see any mention of the file size. I'm (informally) collecting data on that sort of thing ATM, since it's exactly the sort of thing I was referring to, and I've seen enough posts on the list about it to have caught my interest.

FWIW I'll guess something over a gig, perhaps 2-3 gigs...

Also FWIW, while my desktop of choice is indeed KDE, I'm running gentoo, and turned off USE=semantic-desktop and related flags some time ago (early kde 4.7, so over 2.5 years ago now), entirely purging nepomuk, virtuoso, etc, from my system. That was well before I switched to btrfs, but the performance improvement from not just turning it off at runtime (I already had it off at runtime) but entirely purging it from my system was HUGE, I mean like clean all the malware off an MS Windows machine and see how much faster it runs HUGE, *WELL* more than I expected! (I had /expected/ just to get rid of a few packages that I'd no longer have to update, little or no performance improvement at all, since I already the data indexing, etc, turned off to the extent that I could, at runtime. Boy was I surprised, but in a GOOD way! =:^)

Anyway, because I have that stuff not only disabled at runtime but entirely turned off at build time and purged from the system as well, I don't have such a database file available here to compare with yours. But I'd certainly be interested in knowing how big yours actually was, since I already have both the filefrag report on it, and your complaint about how long it took filefrag to compile that information and report back.

Well, you're mounting with compress=lzo (which I'm using too, FWIW), not compress-force=lzo, so btrfs won't try to compress it if it thinks it's already compressed.

Unfortunately, I believe there's no tool to report on whether btrfs has actually compressed the file or not, and as you imply filefrag doesn't know about btrfs compression yet, so just running the filefrag on a file on a compress=lzo btrfs doesn't really tell you a whole lot. =:^(

What you /could/ do (well, after you've freed some space given your filesystem usage information below, or perhaps to a different filesystem) would be copy the file elsewhere, using reflink=no just to be sure it's actually copied, and see what filefrag reports on the new copy. Assuming enough free space btrfs should write the new file as a single extent, so if filefrag reports a similar number of extents on the new copy, you'll know it's compression related, while if it reports only one or a small handful of extents, you'll know the original wasn't compressed and it's real fragmentation.

It would also be interesting to know how long a filefrag on the new file takes, as compared to the original, but in ordered to get an apples to apples comparison, you'd have to either drop-caches before doing the filefrag on the new one, or reboot, since after the copy it'd be cached, while the 5+ minute time on the original above was presumably with very little of the file actually cached.

And of course you could temporarily mount without the compress=lzo option and do the copy, if you find it is the compression triggering the extents report from filefrag, just to see the difference compression makes. Or similarly, you could mount with compress-force=lzo and try it, if you find btrfs isn't compressing the file with ordinary compress=lzo, again to see the difference that makes.

I still say it'd be interesting to see the (from cold-cache) filefrag report and timing on a fresh copy, compared to the 5 minute plus timing above.

Yeah, that's uncomfortably close to full...

(FWIW, it's also interesting comparing that to a df on my /home...

$>> df .
Filesystem 2M-blocks Used Available Use% Mounted on
/dev/sda6 20480 12104 7988 61% /h

As you can see I'm using 2M blocks (alias df=df -B2M), but the filesystem is raid1 both data and metadata, so the numbers would be double and the 2M blocks are thus 1M block equivalent. (You can also see that I've actually mounted it on /h, not /home. /home is actually a symlink to /h just in case, but I export HOME=/h/whatever, and most programs honor that.)

So the partition size is 20480 MiB or 20.0 GiB, with ~12+ GiB used, just under 8 GiB available.

It can be and is so small because I have a dedicated media partition with all the big stuff located elsewhere (still on reiserfs on spinning rust, as a matter of fact).

Just interesting to see how people setup their systems differently, is all, thus the "FWIW". But the small independent partitions do make for much shorter balance times, etc! =:^)

It has come up before on this list and doesn't hurt anything, but those extra system-single and metadata-single chunks can be removed. A balance with a zero usage filter should do it. Something like this:

btrfs balance start -musage=0

That will act on metadata chunks with usage=0 only. It may or may not act on the system chunk. Here it does, and metadata implies system also, but someone reported it didn't, for them. If it doesn't...

btrfs balance start -f -susage=0

... should do it. (-f=force, needed if acting on system chunk only.)

https://btrfs.wiki.kernel.org/index.php/Balance_Filters

(That's for the filter info, not well documented in the manpage yet. The manpage documents btrfs balance fairly well tho, other than that.)

Anyway... 252 gigs used of 252 total in filesystem show. That's full enough you may not even be able to balance as there's no unallocated blocks left to allocate for the balance. But the usage=0 thing may get you a bit of room, after which you can try usage=1, etc, to hopefully recover a bit more, until you get at least /some/ unallocated space as a buffer to work with. Right now, you're risking being unable to allocate anything more when data or metadata runs out, and I'd be worried about that.

That's weird. I wonder why/how, unless it's simply so full an SSD that the firmware's having serious trouble doing its thing. I know I've seen nothing like that on my SSDs. But then again, my usage is WILDLY different, with my largest partition 24 gigs, and only about 60% of the SSD even partitioned at all because I keep the big stuff like media files on spinning rust (and reiserfs, not btrfs), so the firmware has *LOTS* of room to shuffle blocks around for write-cycle balancing, etc.

And of course I'm using a different brand SSD. (FWIW, Corsair Neutron 256 GB, 238 GiB, *NOT* the Neutron GTX.) But if anything, Intel SSDs have a better rep than my Corsair Neutrons do, so I doubt that has anything to do with it.

Of course that's the question of the entire thread. As I said, I have it turned on here, but I understand the arguments for both sides, and from here that question does appear to remain open for debate.

One other related critical point while we're on the subject.

A number of people have reported that at least for some distros installed to btrfs, brand new installs are coming up significantly fragmented. Apparently some distros do their install to btrfs mounted without autodefrag turned on.

And once there's existing fragmentation, turning on autodefrag /then/ results in a slowdown for several boot cycles, as normal usage detects and queues for defrag, then defrags, all those already fragmented files. There's an eventual speedup (at least on spinning rust, SSDs of course are open to question, thus this thread), but the system has to work thru the existing backlog of fragmentation before you'll see it.

Of course one way out of that (temporary but sometimes several days) pain is to deliberately run a btrfs defrag recursive (new enough btrfs has a recursive flag, previous to that, one had to play some tricks with find, as documented on the wiki) on the entire filesystem. That will be more intense pain, but it'll be over faster! =:^)

The point being, if a reader is considering autodefrag, be SURE and turn it on BEFORE there's a whole bunch of already fragmented data on the filesystem.

Ideally, turn it on for the first mount after the mkfs.btrfs, and never mount without it. That ensures there's never a chance for fragmentation to get out of hand in the first place. =:^)

(Well, with the additional caveat that the NOCOW extended attribute is used appropriately on internal-rewrite files such as VM images, databases, bittorrent preallocations, etc, when said file approaches a gig or larger. But that is discussed elsewhere.)

Some people wouldn't call a minute "long", but yeah, on an SSD, even at several hundred gig, that's definitely not "short".

It's not well comparable because as I explained, my partition sizes are so much smaller, but for reference, a trim on my 20-gig /home took a bit over a second. Doing the math, that'd be 10-20 seconds for 200+ gigs. That you're seeing a minute, does indeed seem to indicate high free-space fragmentation.

But again, I'm at under 60% SSD space even partitioned, so there's LOTS of space for the firmware to do its management thing. If your SSD is 256 gig as mine, with 253+ gigs used (well, I see below it's 300 gig, but still...) ... especially if you're not running with the discard mount option (which could be an entire thread of its own, but at least there's some official guidance on it), that firmware could be working pretty hard indeed with the resources it has at its disposal!

I expect you'd see quite a difference if you could reduce that to say 80% partitioned and trim the other 20%, giving the firmware a solid 20% extra space to work with.

If you could then give btrfs some headroom on the reduced size partition as well, well...

Now, yes. As I stressed above, turn it on when the filesystem's new, before you start loading it with content, and the story should be quite different. Don't give it a chance to fragment in the first place. =:^)

Well, of course there's backups. Given that btrfs isn't fully stabilized yet and there are still bugs being worked out, those are *VITAL* maintenance! =:^)

Also, for the same reason (btrfs isn't yet fully stable), I recently refreshed and double-checked my backups, then blew away the existing btrfs with a fresh mkfs.btrfs and restored from backup.

The brand new filesystems now make use of several features that the older ones didn't have, including the new 16k nodesize default. =:^) For anyone who has been running btrfs for awhile, that's potentially a nice improvement.

I expect to do the same thing at least once more, later on after btrfs has settled down to more or less routine stability, just to clear out any remaining not-fully-stable-yet corner-cases that may eventually come back to haunt me if I don't, as well as to update the filesystem to take advantage of any further format updates between now and then.

That's useful btrfs maintenance, SSD or no SSD. =:^)

=:^)

Indeed. I'm running btrfs raid1 mode with my ssds (except for /boot, where I have a separate one configured on each drive, so I can grub install update one and test it before doing the other, without endangering my ability to boot off the other should something go wrong).

Well, yes. But SSDs cost money. And at least here, while I could justify two SSDs in raid1 mode for my critical data, and even overprovision such that I have nearly 50% available space entirely unpartitioned, I really couldn't justify spending SSD money on gigs of media files.

But as they say, YMMV...

---
[1] Pathologic: THAT is the word I was looking for in several recent posts, but couldn't remember, not "pathetic", "pathologic"! But all I could think of was pathetic, and I knew /that/ wasn't what I wanted, so explained using other words instead. So if you see any of my other recent posts on the issue and think I'm describing a pathologic case using other words, it's because I AM!

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

I'm not an expert, but I wondered myself. And while I still have not SSD yet I would prefer turning autodefrag on even for SSD - at least when I have no big write-intensive files on the device (but you should plan your FS to not have those on a SSD anyways) because btrfs may rewrite large files on SSD just for the purpose of autodefragging. I hope that will improve soon, maybe by only defragging parts of the file given some sane thresholds.

Why I decided I would turn it on? Well, heavily fragmented files give a performance overhead, and btrfs tends to fragment files fast (except for the nodatacow mount flag with its own downsides). An adaptive online defrag ensures you gain no performance loss due to very scattert extents. And:
Fragmented files (or let's better say fragmented free space) increases write-amplification (at least for long-living filesystems) because when small amounts of free space are randomly scattered all over the device the filesystem has to fill these holes at some point in time. This decreases performance because it has to find these holes and possibly split batched write requests, and it potentially decreases life-time of your SSD because the read-modify-write-erase cycle takes action in more places than what would be needed if the free space hole had just been big enough. I don't know how big erase blocks [*] are - but think about it. You will come to the conclusion that it will reduce life-time.

So it is generally recommended to defragment heavily fragmented files, leave alone the not-so-heavily fragmented files and coalesce free space holes into bigger free space areas on a regular basis. I think, an effective algorithm could coalesce free space into bigger areas of freespace and as a side effect simply defragment those files whose parts had to be moved anyways to merge free space. During this process, a trim should be applied.

I wonder if btrfs will optimize for this use case in the future...

All in all, I'd say: Defragmenting a SSD is not that bad if done right, and if done right it will even improve life-time and performance. And I believe this is why the wiki recommends it. I'd recommend combining it with compress=lzo or maybe even compress-force=lzo (unless your SSD firmware does compression) - it should give a performance boost and reduces writes to your SSD. YMMV - so do your (long-term) benchmarking.

If performance and life-time is a really big concern then only partition and ever use 75% of your device and leave the rest of it untouched so it can be used as spare area for wear-levelling [**]. It will give you a good long- term performance and should increase life-time.

[*] Erase blocks are usually much much bigger than the block size you can read and write data at. Flash memory cannot be overwritten, it is essentially write-once-read-many, so it needs to be erased. This is where the read-modify-write-erase cycle comes from and why wear-leveling is
needed: Read the whole erase block, modify it with your data block, write it to a new location, erase and free the old block. So you see: Writing just 4k can result in (128k-4k) read, 128k written, 128k erased (so something like a write-amplification factor of 64), given an erase block size of 128k. Do this a lot and randomly scattered, and performance and life-time will suffer a lot. The SSD firmware will try to buffer as much data as possible before the read-modify-write-erase-cycle kicks in to decrease the bad effects of random writes. So a block-sorting scheduler (deadline instead of noop) and increasing nr_requests may be a good idea. This is also why you may want to look into filesystems that turn random writes into sequential writes like f2fs or why you may want to use bcache which also turns random writes into sequential writes for the cache device (your SSD).

[**] This ([*]) is why you should keep a spare area...

These are just my humble thoughts. You see: The topic may be a lot more complex than just saying "use noop scheduler" and "SSD needs no defragmentation". I think those statements are just plain wrong.

Replies to list only preferred.

Am Freitag, 24. Januar 2014, 21:14:21 schrieben Sie:

Do you have any numbers to back your claim?

I just demonstrated that >90000 extent Nepomuk database file. And still I do not see any serious performance degradation in KDE´s desktop search. For example I just entered nodatacow in Alt-F2 krunner text input and it presented me some indexed mails in an instant.

I tried to defrag the file, but frankly even though numbers of extent decreased I never perceived any difference in performance whatsoever.

I am just not convinced that autodefrag will give me any noticeable benefit for this Intel SSD 320 based /home.

For seeing any visible difference I think you need to have an I/O pattern that generated lots of IOPS due to the fragmented file, i.e. is reading and writing continuously large amounts of the fragmented data, yet despite those >90000 extents I get:

merkaba:/home/martin/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend> echo 3 > /proc/sys/vm/drop_caches ; /usr/bin/time -v dd if=soprano-virtuoso.db of=/dev/null bs=1M
2418+0 Datensätze ein
2418+0 Datensätze aus
2535456768 Bytes (2,5 GB) kopiert, 13,9546 s, 182 MB/s
Command being timed: "dd if=soprano-virtuoso.db of=/dev/null bs=1M" User time (seconds): 0.00
System time (seconds): 2.77
Percent of CPU this job got: 19%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:13.96
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 2000
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 2
Minor (reclaiming a frame) page faults: 549
Voluntary context switches: 9369
Involuntary context switches: 57
Swaps: 0
File system inputs: 5102304
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0

So even if I read in the full 2,4 GiB where BTRFS will have to look up all the

Okay, I have seen 260 MB/s. But frankly I am pretty sure that Virtuoso isn´t doing this kind of large scale I/O on a highly fragmented file. Its a database. Its random access. My oppinion is that Virtuoso couldn´t care less about the fragmentation of the file. As long as it is stored on the SSD.

Well… take this with caveat. This is LZO compressed, those 2,4 GiB / 128 KiB gives at least about 20000 extents already provided that my calculation is correct. And these extents could be sequential (I doubt it tough also give the high free space fragmention I suspect to be on this FS).

Anyway: I do not perceive any noticable performance issues due to file fragmentation on SSD and think that at least on highly filled BTRFS filesystem autodefrag may do more harm than good (like fragment free space and then let btrfs-delalloc go crazy on new allocations). I know xfs_fsr for defragmenting XFS in the background, even via cron job. And I think I remember Dave Chinner telling in some post that even for harddisks it may not be a very wise idea to run this frequently due to the risk to fragment free space.

There are several kinds of fragmentations. And defragmenting files may increase freespace fragmentation.

Thus, I am not yet convinced regarding autodefrag on SSDs.

Ciao,

Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

I think it makes no real difference here since access to virtuoso is random anyway. And if I got you right you run it nocow, so upon writes you aren't introducing more fragmentation to the file. All is good... It probably would even be good with cow as virtuoso is read-most, so rarely written to.

For VM images it might be a whole different story. The guest system sees a block device and expects it to be continuous. All optimizations for access patterns cannot work right if btrfs is constantly moving parts of the file around for doing cow. So make it nocow and all should be as good as it can get.

Your CPU is more mighty than the flash chips. LZO improves read performance. But does it make sense on Intel drives? I think they already do compression.

This is why I wondered if btrfs will be optimized for keeping free space together in the future for SSD. But it's not as simple as this. It should not scatter file blocks all over the disk just to fill tiny holes. It should try to keep file blocks together so the read-modify-write-erase cycle of SSDs can work optimally.

I think everything would be easier if btrfs exposed some stats about what the autodefrag thread is really doing...

Replies to list only preferred.

Am Samstag, 25. Januar 2014, 15:06:24 schrieb Kai Krakow:

No, its not nocow.

I have some VirtualBox based VMs. I never see any issue with that. They are just fast. But then, for write based workloads I read hints that Virtualbox may not honor fsync() that closely.

Not the Intel SSD 320 to my knowledge.

I am reluctant about conclusions about the behavior or SSDs. I am not sure whether a modern SSDs cares that much about scattering file blocks all over the disk. AFAIK all modern SSDs don´t tell the OS a thing about in which erase block they store something and all SSDs use some caching. So a modern SSD may just sort several write accesses even if there are at different ends of the block device together into adjacent erase blocks. Well, actually I think thats the whole point of SSD firmwares. I am pretty much sure that the blocks of the block device that Linux sees are not mapped sequentially to flash chips by the SSD firmware. AFAIK all SSDs have some internal mapping.

So I wonder whether it even matters…

Heck a SSD firmware even copies over stuff to distribute erase cycles evenly onto all flash chips in the background and whatnot.

… and if we actually knew how SSD firmwares really behave.

But well… regarding autodefrag… I don´t know… my gut feeling is to disable it for SSDs for the reasons I outlined.

Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7