Timeline for How to defrag an ext4 filesystem
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 6 at 15:56 | comment | added | Mikko Rantalainen |
I think you should do shrink + grow to defrag the free space and then do e2defrag for the whole filesystem to defrag the files as much as possible.
|
|
| Nov 18, 2022 at 9:27 | comment | added | abukaj |
Moreover, its efficiency depends on the filesystem settings. I have filesystem created with mke2fs -O extent,flex_bg -G 4096 which is 49% full, but gparted can shrink its size to 99% only - thus fragmentation of free space remains almost the same.
|
|
| Nov 16, 2022 at 22:17 | comment | added | abukaj |
Followed your procedure. According to e2defrag output, the number of extents actually increased. Seems that it does not defrag files. It defrags free space.
|
|
| Nov 16, 2022 at 21:09 | comment | added | abukaj | Why do you need to the very end of HDD rather than just enough it does not overlap with its previous location? | |
| Apr 13, 2017 at 12:25 | history | edited | CommunityBot |
replaced http://askubuntu.com/ with https://askubuntu.com/
|
|
| Oct 8, 2015 at 0:43 | comment | added | Shnatsel | Any tips on how this interacts with logical partitions? For example, Ubuntu creates a logical partition by default with actual swap and ext4 partitions inside it. What should I do if the actual partition I want to defrag is inside a logical partition? | |
| May 18, 2015 at 23:21 | comment | added | Ivan | There is a great reasons to defrag your files regularly: it is much easier to recover contiguous, non-fragmented files in case of a file system failure. | |
| Jan 19, 2015 at 23:13 | history | rollback | James |
Rollback to Revision 3
|
|
| Jan 15, 2015 at 10:49 | history | edited | Fabby | CC BY-SA 3.0 |
Changed "just over the amount of your data" to "twice your largest file"
|
| Oct 22, 2013 at 23:05 | comment | added | Jason C | Ah, we are miscommunicating. You meant reorder the partition so it is last. I meant move the partition to the end of the drive, and that's what I thought you meant as well (you can move partitions around on the drive with gparted independently of reordering them). :) | |
| Oct 22, 2013 at 23:03 | comment | added | Jason C | Moving it to the right does move it to the end of the hard drive. The partition bar at the top of the gparted GUI is actually an accurate representation of the data layout (well, at least as visible to the OS, flash devices for example map logical to physical locations on the other side of the controller, but for a typical HDD, it is accurate). This can be verified by observing the new start location in the partition table. :) | |
| Oct 22, 2013 at 22:04 | comment | added | James | Simple moving the partition you want to defrag to last does not necessarily move it to the actual end of the HD. Growing the partition to the left to maximum size makes sure that the end partition is actually "moved" to the very end of the hard drive. | |
| Oct 22, 2013 at 18:59 | comment | added | Jason C | Also I noticed that after the grow-left step, the data itself was actually moved left again (evidenced by gparted moving data, verified by a direct examination of the block device afterwards), so unless that is version/filesystem-dependent behavior the final shrink + regrow can be skipped. It appears to be sufficient to only do: 1) shrink and move right, 2) apply, 3) grow left. | |
| Oct 22, 2013 at 17:47 | comment | added | Jason C | After shrinking and moving right, why do you grow left then shrink again instead of just moving left? | |
| Apr 27, 2013 at 12:13 | vote | accept | CommunityBot | ||
| Dec 18, 2015 at 15:59 | |||||
| Dec 21, 2012 at 0:10 | history | edited | James | CC BY-SA 3.0 |
improved formatting
|
| Nov 23, 2012 at 21:39 | history | edited | James | CC BY-SA 3.0 |
deleted 40 characters in body
|
| Nov 23, 2012 at 21:34 | history | answered | James | CC BY-SA 3.0 |