Timeline for Do ext4 filesystems need to be defragmented?
Current License: CC BY-SA 4.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 10, 2023 at 11:57 | comment | added | Artem S. Tashkinov | I know, systemd-journald log files are owned by root. In fact in my root partition I have barely any files which are not owned by root. I've run this command, it didn't change anything: pastebin.com/raw/rEPXr9MB | |
| Jun 10, 2023 at 11:35 | comment | added | Валерий Заподовников | Only one user (usually root) can write into the reserved blocks... -u option controls it: unix.stackexchange.com/a/8042/360526 What can also work is writing zeroes into all free space and then deleting it. It will force the ext4 to defragment free space and files, by force as in by design. | |
| Jun 10, 2023 at 10:27 | comment | added | Artem S. Tashkinov |
60,508,368 B in 42 files - nothing to write home about. tune2fs -r 0 /dev/sda1 - this is inconsequential.
|
|
| Jun 10, 2023 at 10:18 | comment | added | Валерий Заподовников | How big are biggest files in your /var/log? You can clean them with "> /var/log/messages", also ext4 always has extra free space because of this genius reserved design. You can make it 0 using: tune2fs -r 0 /dev/sda1 | |
| Jun 9, 2023 at 11:49 | comment | added | Artem S. Tashkinov |
You can read all you want, the question is how you will make the kernel put the files where you want them to be. Here's my issue: /dev/root 20G 6.0G 13G 32% / - 13GB free (!), yet five files around ~150MB (libxul.so x2, the chrome binary and some NVIDIA libraries) cannot be defragmented as free space is fragmented as hell. I've just given up. It's XFS/NTFS or bust :-)
|
|
| Jun 9, 2023 at 10:27 | comment | added | Валерий Заподовников | I deleted /var/log 15 GB log files and it allowed me to defragment most of the files. And you know the underlying layout... You can read segments and inodes directly... | |
| Jun 9, 2023 at 10:21 | comment | added | Artem S. Tashkinov | @ВалерийЗаподовников Nah, not going to work. OK, you've moved large files off to RAM. How will you make the kernel relocate smaller files which are already fully defragmented? And those small files are dispersed evenly all over the disk. You may as well ... use option 1 that I offered earlier. Someone could ask kernel devs to implement the API to force the kernel to move files close to each other. It shouldn't be too difficult. But without knowing the underlying layout you'll never do that efficiently - it will be a wild guess and it more likely won't have a good effect. | |
| Jun 9, 2023 at 6:21 | comment | added | Валерий Заподовников | Algorithm: use RAM to offload some files from hard drive in a smart way to defrag biggest files. I mean... How hard can it be? | |
| Jun 8, 2023 at 10:21 | comment | added | Artem S. Tashkinov | @ВалерийЗаподовников Directly for ext4? You cannot. Indirectly: 1) Backup/format (that's necessary)/restore 2) Shrink as much as you can, expand back. Then defrag again. If you're concerned about defragging free space, you really could use XFS instead or even NTFS which must work near perfectly with Linux using the ntfs3 driver. | |
| Jun 8, 2023 at 10:07 | comment | added | Валерий Заподовников | Do you have any idea how to defragment free space? Also, yes the defrag script should be in path ./defrag will not work. | |
| Apr 30, 2023 at 14:53 | history | edited | Artem S. Tashkinov | CC BY-SA 4.0 |
deleted 2 characters in body
|
| Nov 7, 2022 at 17:23 | comment | added | Atomic Tripod |
I needed to save the script you made to /usr/local/bin/defrag (no .sh). See askubuntu.com/questions/222361/…
|
|
| Nov 6, 2022 at 18:33 | comment | added | Artem S. Tashkinov | @JimmyCarter I'm not sure what you've aliased. You may want to ask a question on unix.stackexchange.com/questions | |
| Jun 20, 2022 at 13:19 | history | edited | Artem S. Tashkinov | CC BY-SA 4.0 |
-f flag for e2fsck is required in many cases
|
| Jun 18, 2022 at 7:14 | comment | added | Artem S. Tashkinov |
The -n flag should be enough, maybe it's relatively new.
|
|
| Jun 17, 2022 at 22:46 | comment | added | BenjiWiebe |
Fedora 33. e2fsck 1.45.6 (20-Mar-2020). EDIT I see what's going on. Your e2fsck command was ran against a partition that wasn't cleanly unmounted. You need to add a -f to force checking of a clean partition.
|
|
| Jun 17, 2022 at 20:18 | comment | added | Artem S. Tashkinov | It showed fragmentation status as early as 10 years ago. Are you using Debian 9? RHEL 7? | |
| Jun 17, 2022 at 17:48 | comment | added | BenjiWiebe | Yes I am running a slightly older version. Apparently that was added fairly recently. | |
| Jun 16, 2022 at 22:53 | comment | added | Artem S. Tashkinov | @BenjiWiebe this doesn't look right, here's my output: pastebin.com/raw/7rwJxySk Either you're not using it right, or it's an old version, or there's a bug. | |
| Jun 16, 2022 at 22:42 | comment | added | BenjiWiebe | I checked the e2fsck command you mentioned, and on my system it does not say how fragmented the partition is. It lists the total number of files and the total number of blocks. It does not say what percentage is contiguous. | |
| Jun 14, 2022 at 15:21 | history | answered | Artem S. Tashkinov | CC BY-SA 4.0 |