You are not logged in.
Pages: 1
Hi all,
My desktop has a Samsung 850 Pro 256 GB ssd ext4 filesystem. I have configured trim using the fstrim.timer, and that is running fine according to the timestamp on the stamp-fstrim.timer file.
When I run fstrim -a -v manually it reports back something like 127GB trimmed. Then I wait for a few seconds and run fstrim -a -v again and the counter is back at something like 650MB.
All the while the only other thing running is firefox and konsole.
Is there any way to find out which process is causing the drive to be "filled"?
I see this same behavior on both our desktop pc's.
Thanks for the help!
Last edited by woodchip (2018-06-21 17:28:44)
Offline
sudo iotop -a
...firefox and session restore functionality is known to write a lot of data to disk while you're browsing; fortunately that's tunable.
This post is old, now it does not write much while idling, but problem persists while browsing:
https://www.servethehome.com/firefox-is … to-fix-it/
tl;dr?
Change browser.sessionstore.interval in about.config to something much higher.
Last edited by kokoko3k (2018-06-21 20:55:15)
Help me to improve ssh-rdp !
Retroarch User? Try my koko-aio shader !
Offline
Thanks kokoko3k,
I have looked into that, but it does not really give any insights, iotop does not list a process which is writing that much. I have altered the firefox setting and this helps with the write during browsing. Thanks!
Also I have tried the following:
Clean system start:
sudo fstrim - a -v
/: 127.9 GiB (137271107584 bytes) trimmed
sudo fstrim - a -v
/: 0 B (0 bytes) trimmed
So seems clean then, reboot the system:
after reboot:
sudo fstrim -a -v
/: 127.9 GiB (137271107584 bytes) trimmed
Exact same number to be trimmed after reboot...
Is this normal behavior? Has it something to do with the fstrim command not knowing having already trimmed the drive?
Last edited by woodchip (2018-06-22 08:15:44)
Offline
-v, --verbose
Verbose execution. With this option fstrim will output the
number of bytes passed from the filesystem down the block
stack to the device for potential discard. This number is a
maximum discard amount from the storage device's perspective,
because FITRIM ioctl called repeated will keep sending the
same sectors for discard repeatedly.
I'm interpreting that as the hardware decides which number to report here, so I'd assume that it might be specific for that firmware to simply check everything and then having relevant information cached that gets reset on power loss/cycle
Offline
So it is probably by design then.
Offline
Also I have tried the following:
Clean system start:
sudo fstrim - a -v
/: 127.9 GiB (137271107584 bytes) trimmed
sudo fstrim - a -v
/: 0 B (0 bytes) trimmedSo seems clean then, reboot the system:
after reboot:
sudo fstrim -a -v
/: 127.9 GiB (137271107584 bytes) trimmedExact same number to be trimmed after reboot...
On my Dell Ultrabox with an SSD: Micron model: C400 RealSSD mSATA 32GB I've had exactly the same behavior when restarting too.
With ext4 - open Chromium and Xterm.
[judd@arch ~]$ LANG=C sudo fstrim -a -v
[sudo] password for judd:
/: 19.1 GiB (20500537344 bytes) trimmed
[judd@arch ~]$ LANG=C sudo fstrim -a -v
/: 0 B (0 bytes) trimmed
[judd@arch ~]$
Last edited by judd1 (2018-06-22 11:48:49)
This isn't right. This isn't even wrong.
-- Wolfgang Pauli --
Offline
The information about what has been trimmed is not stored on disk by ext4, so after a reboot it will always trim all the free space, which might have already been trimmed before, no harm done there I suppose.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Pages: 1