Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
You should use 'noatime' or 'relatime' regardless of the media or filesystem. 'atime' was a bad idea when it was implemented, SSD didn't change that.
additional on mine:
make sure fstrim in crond that triggesr once a week for trimming.
not necessary if the filesystem supports discard. (aka: trim)
On a related note, I have a seagate SAS SSD I got for a ZFS SLOG device. It seems to be performing okay, but when I tried to trim it, I got this:
Discarding device blocks: failed - Input/output error
Looking in the log, I see a bunch of scsi reset messages. The SSD seems to be performing okay, so I'm not sure if there's an issue here. Is it okay to do a low-level scsi format to make sure everything is cleaned up?
Yes, but more research indicates it might be a known issue with some seagate SAS drives reporting one sector too many or something. I'm inclined to not mess with it unless given a reason to
I use discard because fstrim always just says "0 bytes trimmed" so it appears to not be working.
discard is handled automatically by kernel when enabled during mounting.
fstrim is a "tool" to notify kernel to do trim manually by assuming discard is not in mount option.
either one must be used, NOT both
when t some files are deleted or truncated (as I my understandong on linux kernel), trim command executed by kernel if discrad is ENABLED or fstrim is EXECUTED.
if you see "0 bytes trimmed", that is possible discrad is in mount option or No file deletion and truncation occures..
I do not use both. I used to use none. Then I learned about fstrim, but I could not get it to work. It was always "0 bytes trimmed" and it returns with this message instantly when I run it.
What exact command and args are you calling fstrim with?
What is the filesystem on the device you are trying to trim? Is the filesystem installed directly on the block device, or are there partitions or LVM?
root@nick-server:~# fstrim / -v
/: 0 bytes were trimmed
root@nick-server:~# fstrim /mnt/misc -v
/mnt/misc: 405372834 bytes were trimmed
root@nick-server:~# mount
...
/dev/sda1 on / type btrfs (rw,relatime,ssd,space_cache)
/dev/sda2 on /mnt/misc type ext4 (rw,noatime,errors=remount-ro,data=ordered)
...
root@nick-server:~# fdisk -l /dev/sda
Disk /dev/sda: 256.1 GB, 256060514304 bytes
255 heads, 63 sectors/track, 31130 cylinders, total 500118192 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0006fbdb
Device Boot Start End Blocks Id System
/dev/sda1 2048 209717247 104857600 83 Linux
/dev/sda2 209717248 500117503 145200128 83 Linux
root@nick-server:~# parted /dev/sda print
Model: ATA M4-CT256M4SSD2 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 107GB 107GB primary btrfs
2 107GB 256GB 149GB primary ext4
Yeah, I wish I knew a way to update util-linux without breaking my whole machine.
I'm OK with the discard mount option solution, but I have no way of knowing if it's actually working :\
Yeah, I wish I knew a way to update util-linux without breaking my whole machine.
I'm OK with the discard mount option solution, but I have no way of knowing if it's actually working :\
taken from your link ....Interesting that it works on ext4 but not btrfs for you.
I have used fstrim on XFS and ext4 filesystems, and it works as expected. I have not tried btrfs.
If your version of fstrim is old, that might explain why it does not work on btrfs. btrfs is such a moving target.
noatime,discard in fstab
I don't bother with scheduler, kernel takes care of that, since you could have a mix of SSD & rotating disks.
I'm not even sure how exactly TRIM is supposed to work on a COW filesystem like btrfs in cases where you have snapshots. If you delete a file in a directory that is part of a snapshot, I suppose fstrim would not free any sectors. And there may be other complications I have not thought of.
as I understand,
if fstrim does not work, discard is not working too, since fstrim triggers kernel to do send trim execution(command).
as I understand, trim is lower level than filesystem such as: xfs, btrfs, ext4, etc.
if the filesystem deletes some space (not related with deleting same file in snapshot which is not real deletion in low level), trim will reclaim as free memory/space.
SSD does not have sectors .
trim just reclaim free (deleted) memory.
please correct me.........
So if TRIM isn't working either way what options do I have? heh.
What exactly are the consequences I should expect of not having a functional TRIM over time. I've had this system running for 6 months so far. Something about slower performance, right? But is really that bad? Does it eventually hit a bottom point or does it get worse to infinity?
You are confusing internal SSD structure with the OS and filesystem interface to the device. A filesystem does NOT "delete some space". The filesystem is responsible for keeping track of where on the block device data is stored, but outside of TRIM, a filesystem does not bother to "delete". It just overwrites blocks that are no longer allocated to files.
An SSD does have logical sectors (aka LBAs), like all ATA devices. That is the interface (API, if you will) that the SSD presents to the OS.
I haven't looked at the fstrim code, but it is obvious that fstrim must somehow inform the filesystem either that the filesystem needs to TRIM the unused sectors, or else the filesystem must inform fstrim what sectors may be TRIMmed and then send the TRIM commands itself. Either way, you have two key things that must take place:
(1) the filesystem must identify the sectors (LBAs) that may be TRIMmed
(2) the TRIM command must be sent to the SSD for those sectors
Since fstrim, when it fails for SirMaster, appears to know that nothing has been TRIMmed, my guess is that the failure is occurring in step (1). Although I suppose it is still possible that step (2) occurs and fstrim recognizes the error message and so knows that nothing has been TRIMmed, I guess that is not the problem.
So if TRIM isn't working either way what options do I have? heh.
What exactly are the consequences I should expect of not having a functional TRIM over time. I've had this system running for 6 months so far. Something about slower performance, right? But is really that bad? Does it eventually hit a bottom point or does it get worse to infinity?
I wish there was a way to confirm if it is working with discard.
Well there is this and I don't think it's really specific to ext4:
https://sites.google.com/site/lightrush/random-1/checkiftrimonext4isenabledandworking
No. As even that link warns, there is no guarantee that TRIMmed sectors will be read as zeros by the SSD.
No, but the link does mention that if it is read as zeros it's working.
Well there is this and I don't think it's really specific to ext4:
https://sites.google.com/site/lightrush/random-1/checkiftrimonext4isenabledandworking
root@nick-server:/# hdparm --fibmap tempfile
0,17: device not found in /dev