Good Article on the EXT file system

[TWPonKubuntu]

The author, David Both, gives a useful comparison of the four EXT file variations and compares them to BTRFS (B-Tree File System). I Learn some things from this article, you may also.

https://opensource.com/article/17/5/...xt4-filesystem

[GreyGeek]

MMMM.... Somewhat confusing:

EXT4 reduces fragmentation by scattering newly created files across the disk so that they are not bunched up in one location at the beginning of the disk, as many early PC filesystems did. The file-allocation algorithms attempt to spread the files as evenly as possible among the cylinder groups and, when fragmentation is necessary, to keep the discontinuous file extents as close as possible to others in the same file to minimize head seek and rotational latency as much as possible.

As I understood it, and defragmentation programs displayed it, fragmentation occurred when a files sectors were scattered all over the disk, resulting in increased head movement and seek times. The defrag programs would gather a file's sectors together in one sequential read to minimize head movement. As I read that article, the author appears to be saying the exact opposite.

Regardless, EXT3, and then EXT4, are great file systems, especially with the introduction of the journal. With the journal a computer could suddenly lose power (power brownout, blink or outage) and when it was rebooted the journal would play out and restore the fs and its data. I used that feature to sell Linux to the suites. One asked me "What happens if the power goes out while the computer is on?". I replied "Like this?", and pulled the power cord out of the wall. When that desktop came back up the shell script menu was showing nicely on the screen, ready for action. I've had more than one power interruption since I moved to Btrfs and its journal system recovers nicely as well.

As nice as EXT4 is, I'll never go back to it since I moved to Btrfs. It has so many backup and recovery features that are far superior to EXT4 without the need of external software. In 2 1/2 yrs of use it hasn't so much as hiccuped. Also, I use the RAID1 feature that Btrfs supports, and it is very nice.

[SpecialEd]

MMMM... Somewhat confusing:

As I understood it, and defragmentation programs displayed it, fragmentation occurred when a files sectors were scattered all over the disk, resulting in increased head movement and seek times. The defrag programs would gather a file's sectors together in one sequential read to minimize head movement. As I read that article, the author appears to be saying the exact opposite.>>>>>>>>>.

He's talking about scattering entire files across the drive not fragments of files. So each file is in a different corner so-to-speak with plenty of space around it for adding data.

[TWPonKubuntu]

GG; I think SpecialEd said it before I did. The individual files are not fragmented, but rather continuous. Their starting locations are spread more or less evenly across the available disk space, including enough "free" space to allow for later file size changes which would prevent fragmenting the expanded file.

The btrfs appears to only have one caviate, relating to SSD read/write limitations. I would hope that future SSD designs can increase the read/write cycle limits... Perhaps they already have done so?

[GreyGeek]

.....

The btrfs appears to only have one caviate, relating to SSD read/write limitations. I would hope that future SSD designs can increase the read/write cycle limits... Perhaps they already have done so?

Oshunluver had and excellent comment, in another thread, about SSD and TRIM:

As far as the SSD, common wisdom is to not use trim as a mount option as it's unnecessary and causes excess wear and drive usage. The preferred method is to "manually" run trim periodically. *buntus accomplish this through a weekly cron job, which I believe is the default. Personally, I think even weekly is too often for most users. Monthly or even less often makes more sense.