Preferably answers from openSUSE team or people who know discussions about the decision.
1 Like
Dont know much about why the opensuse team chose to keep it off by default but in my opinion it is a reasonable descision.
Auto-defrag is great for small files like text documents and mabe the odd MP3 but as soon as you start to use more of your disk with larger files, auto defrag can seriously slow down disk acess, especially on lower end systems, not to mention the performance drops.
I have found this out personaly in linux but it especially hit me hard when I am using my old mac… even opening basic apps like finder became tedious and it took some tinkering under the hood to figure out why…
With the industry steadily moving away from harddrives, most of these old issues may not be encountered as frequently so it is unlikely some of these old bugs will be descovered or cause enough of an issue to have a developer fix it. if you find it to be a big issue however, you should report the bug or push a fix on the btrfs code. it could potentially be disabled by default to avoid issues with ssd’s if there is no detection method employed to trigger auto-defrag.
in the meantime, you could enable auto defrag or, like me, set your drives to automatically defragment during the night or a time when you are unlikely to be using your computer. alternatively you could defrag manually when you feel a performance drop from fragmented files or switch to a different filesystem if it becomes too much of an issue to try and fix.
Most people would reccomend swithing to an ssd and while they do have great performance, the capacities are not wuite there yet and they can suffer from some longjevity issues if frequent read/write operations occur frequently. I would personally reccomend sticking to your spinning disk untill it fails or tyou need the extra performance offered by sold state storage because for some people, the price per gb is still too high in large drives…
Thanks
Luca
1 Like
I also don’t have any inside information, but would just add that defragmentation on systems that are multithreaded/multiuser systems tends to be less necessary or useful in a lot of cases, because the HDD isn’t generally reading or writing a single file sequentially, but rather is reading and writing multiple files concurrently, so the performance increase of having files stored sequentially on the drive is generally lost.
Defragmentation was really useful on DOS because of the generally single-task functionality of the system. It’s just far less useful now in general usage, and the increase in I/O (as luca says) can actually slow things down for the end user.
1 Like
There are some scattered informations available. It would need some quite good logic for the installer/partitioner to detect if a HDD ot SSD is used in your computer. btrfs autodefrag on a HDD won’t do much harm (in therory) whereas applied on a SSD it will destroy/wear it in really short time as there is a heavy write amplification. There are many bugs regarding btrfs autodefrag in combination with SSDs which will finaly lead to a destroyed/worn out SSD. So i believe the openSUSE devs decided to switch of btrfs autodefrag by default to make sure the user data is safe and no logic (SSD/HDD) is needed.
The user is still able to run defrag manually as example with
btrfs fi defrag
2 Likes
Unlike dealing with Windows partitions that fragment quickly, Linux does not seem to have that issue. Like hui said, you can run it manually, and I don’t think you will need to do it very often. Maybe every few months, and you may find you don’t need to do it that often. Certainly not every week, like Windows. 
1 Like
I’m in agreement with previous replies, so will save me some typing 
.
Sometimes it’s beneficial for folks to understand the OP’s current OS trend (and maybe recent past). What are your concerns?
My opinion deviates slightly from one comment, in that I think SSDs are the better option (these current days) than HDDs (for personal use). Form factor, ease of installation, no moving parts, general positive acceptance, etc.
Back to the defrag subject. I’ve forgotten the last time I’ve ever run a defrag on a permanent drive. And actually, the thought has never crossed my mind. Maybe when I had a laptop running Win, about four years ago (only for historical reasons).
So, in these modern times, I think defrag is a moot point
.
.
(sidenote: been running Linux (primarily SuSE) for years and years)
1 Like
I’ve heard btrfs snapshotting and CoW nature cause big fragmentation of files. I’ve also heard fragmentation is bad for HDD.
Generally it’s not bad for the hardware, from everything I have read and know about HDD technology over the decades.
Ultimately, it used to come down to performance, but as I noted, that was with single-user (and generally single-process) systems, and only with sequential file access.
With modern operating systems, sequential file access is a rarity. I use the ‘defragment’ option on my VMware VMDK files (on an SSD, no less) more or less out of habit rather than because of performance improvements. I probably should actually stop doing it, because of the wear it causes to the SSD to just move files around for no reason.
unless you are short for space on your host ssd and your vmdk is dynamically expanding, I would highly reccomend you never do it again: premature wear on ssd’s kills them - it has happened to me with the page file on windows - just a few bad bits of flash is enough to ruin the whole drive.
all defraging a vmdk does is reorganise the blocks, think of it like sliding sandpaper across a plastic floor. the more you do it, the more wear.
on ssds, you dont even need to gefrag becuse there will be little to no performance boost as thy do not have an arm that needs to move and a disk that needs tospin to the correct angle to read a bit of data.
1 Like
For vmdk’s (virtual machine disk images??) i believe you can turn CoW off for them, and also make them sparse files?
yep, seperate files is better and does not need defragmentation like the single file does
To my knowledge, they’re essentially always sparse files - null blocks in the VMDK file aren’t allocated on-disk in the host after you run the ‘compact’ option.