Trim Not Enabled

  • @ryecoaaron Thank you for your answers. i am not paranoid Its the nature of me not wanting to use something without knowing the why. Its also what keeps me learning things.


    Anyway you mentioned above to your answer to @tinh_x7 that he has to check if his drive supports discard.


    After reading some info on how to check that I only came across how to check about trim support with command lsblk -D and checking the result <<TRIM/discard is available, if the DISC-MAX column is not 0B>>



    Mine:



    So it seems to support it.



    Now if I run the command


    Code
    fstrim --verbose --all
    
    
    I get the output
    
    
    root@openmediavault:~# fstrim --verbose --all
    /sharedfolders/Appdata: 90.3 GiB (96997376000 bytes) trimmed
    /: 13.1 GiB (14060220416 bytes) trimmed

    Does this feel like running the command manually? So I could somehow to create a cron task to run it regurarely?

    • Offizieller Beitrag

    I've used the flash-memory plugin on my SSD for.. 3yrs? Never a problem. I figure SSD's and Flash Drives are very similar technology, so it really can't hurt anything. When I helped my buddy built his NAS around 6mo ago, he bought one of those cheap "King Dion" (or something like that) SSD's off of Newegg for about $13 bucks. We used the flash-memory plugin on it and he's never reported to me it was an issue. Unlike a lot of SSD's a lot of those are available in sizes that are perfect for OMV (8, 16gig) where finding those sizes in more main stream brands of SSD's is near impossible. If you intend to use the SSD for only the OS (as it's designed), you end up buying at least a 64gb drive and it results in a ton of wasted space.

  • If you intend to use the SSD for only the OS (as it's designed), you end up buying at least a 64gb drive and it results in a ton of wasted space

    If you 'need' just 16 GB and buy a 64 GB media then the simple math is: with same 'SSD quality' and same write access pattern the media will last four times longer (64 / 16 = 4). if based on your access pattern your drive would've been worn out after 5 years it will now last 20 years. If you enabled the flash memory plugin and your 16 GB drive would've been worn out after 500 years it's now 2000 years. It's as easy as this.


    But unfortunately the math is not entirely precise because you can't trust in those cheap crap King* SSDs (be it Kingdian or Kingspec). They often fake SMART readouts (so you can neither read out an internal SSD temperatiure sensor nor query the 'wear out indicator' good SSDs provide) and they lack/fake TRIM capabilities. Those King* thingies will die way earlier than quality SSDs. But again: when using the flashmemory plugin this doesn't really matter as long as no other constant writing activities happen on the SSD (Docker containers, Plex database and so on).

    • Offizieller Beitrag

    I don't disagree w/ anything you said. To me though since it's just the OS on the drive w/ a normal install, you also have to consider price. I keep nothing on my OS drive but my OS.... which totals out around 3-4gigs IIRC (can't look at the moment). Is it worth it to spend much bigger $$$ for drive that is massively to big, or spend $ for a drive that is almost perfectly sized, but may not be as reliable? Since I keep zero data on my OS drive, to me the answer is pretty simple.


    Even if that Kingdian drive lasts him 2yrs... it was 16 dollars. I know he had no illusions it was the quality of that SSD was higher than that of Sandisk, Crucial, etc. When we talked about his SSD, he felt the money saved was better put towards higher quality data drives.


    To this point, I can't really disagree w/ him... but as I said earlier, it's only been about 6mo.

  • Even if that Kingdian drive lasts him 2yrs...

    If he enabled the flashmemory plugin and there's nothing else that constantly writes to the SSD the SSD won't wear out due to write activity for the next few hundred years anyway.


    My point is that using crappy SSDs makes as much sense as using other inferior flash storage that doesn't occupy a SATA port: there's not much difference to using USB thumb drives or SD cards once the SSD is real crap. And the criteria is missing TRIM support and missing/fake SMART data.


    Quality SSDs all allow to monitor their health and as such there's no need to get any disruption due to a dying SSD. You simply check via SMART the SSD's wear out indicator (smart ssd wear level web search needed since this SMART attribute is vendor specific) and replace it once the SSD indicates it will die soon (based on a bunch of tests made the majority of quality SSDs will work a lot longer than predicted by SMART's 'wear out indicator' so this is really only for paranoid people -- normal people expect hardware dying anytime and do backups).

  • I figure SSD's and Flash Drives are very similar technology, so it really can't hurt anything.

    Even though its true I got stuck by technodad's video mentioning <<beware of this is the third time i m using this because got by system locked>> and if you followed my conversation with ryecoaaron, I just noticed that even if he installs flash plugin he ends up modifying a few lines in the /etc/fstab file which already pre-exists and someone could just edit it without installing the plug in. In conclusion to this issue I can;t understand the extra benefit of having this plug in installed if you end up modifying a file that already pre-exists and isnt been created by the flash plug in.


    PS How could this plugg in lock up the system? Which of his options / arguments whatever makes it dangerous for a potential lock?



    Unlike a lot of SSD's a lot of those are available in sizes that are perfect for OMV (8, 16gig) where finding those sizes in more main stream brands of SSD's is near impossible. If you intend to use the SSD for only the OS (as it's designed), you end up buying at least a 64gb drive and it results in a ton of wasted space.

    True about sizes. Also mine is an intel 128gb which I have partitioned in order to use the 16-32gb for OS space and the other 80gb for a possible VM installation (because of the potential snappiness it would have if it s installed upon an ssd) Probably have a third partition for Appdata but not really sure if I have that in a seperated partition or not.



    But unfortunately the math is not entirely precise because you can't trust in those cheap crap King* SSDs (be it Kingdian or Kingspec). They often fake SMART readouts (so you can neither read out an internal SSD temperatiure sensor nor query the 'wear out indicator' good SSDs provide) and they lack/fake TRIM capabilities. Those King* thingies will die way earlier than quality SSDs. But again: when using the flashmemory plugin this doesn't really matter as long as no other constant writing activities happen on the SSD (Docker containers, Plex database and so on).

    Many good points in the above paragraph. One notice though. You say <<this doesn't really matter as long as no other constant writing activities happen on the SSD>> but swap will constantly write small data. If you disable it in fstab by commenting out the line reffering to the swap (at least that is what I came to understand of a way to disable it) then how will you calculate the amount of ram is being used for swap and what if in a big copy paste full the ram and fail.

  • but swap will constantly write small data

    Why/how? Swap will only be used when needed since kernel developers aren't idiots. This is how it looks like on a large filer with some GB swap configured (by the installer at installation time):


    Code
    tk@datengrab:~$ free
                  total        used        free      shared  buff/cache   available
    Mem:       64593452    35031984    28017176        2924     1544292    28833956
    Swap:       7194620           0     7194620

    0 bytes used. And even if some swap is used this is nothing bad since the kernel pages out stuff that won't be needed in RAM. Only if you're really low on RAM you need to take care about your swap settings and then with an SSD I would immediately explore zswap (this uses the SSD as backend storage for data that doesn't change and limits the 'normal swap activity' to compressed RAM).

    • Offizieller Beitrag

    Even though its true I got stuck by technodad's video mentioning <<beware of this is the third time i m using this because got by system locked>> and if you followed my conversation with ryecoaaron, I just noticed that even if he installs flash plugin he ends up modifying a few lines in the /etc/fstab file which already pre-exists and someone could just edit it without installing the plug in. In conclusion to this issue I can;t understand the extra benefit of having this plug in installed if you end up modifying a file that already pre-exists and isnt been created by the flash plug in.
    PS How could this plugg in lock up the system? Which of his options / arguments whatever makes it dangerous for a potential lock?


    https://forum.openmediavault.o…php/User/4556-ryecoaaron/

    Usually the "lock up" will be caused when someone doesn't edit their fstab properly and it results in the root file system being marked read only. You can find multiple threads on this throughout the forum as it has happened to lots of folks.


    As for needing the plugin enabled or not... I asked @ryecoaaron about that a while ago and he mentioned the plugin being installed also made some other changes, and the fstab edits were just the final thing to make it all work together (I had the same theory as you, why not just add those options to fstab w/o installing the flash-memory plugin). That was many moons ago when the plugin was first made, so it's quite possible things have changed since then.


    As long as you pay attention, locking your system up while editing the fstab for the flash-memory plugin is really a pretty remote possibility. I've personally never locked up my system doing this, but there's been plenty of threads here where people have.

  • Only if you're really low on RAM you need to take care about your swap settings and then with an SSD I would immediately explore zswap (this uses the SSD as backend storage for data that doesn't change and limits the 'normal swap activity' to compressed RAM).

    Your recommendation intrigued me to search for it but didnt find adequate info to use it (the implementation is already there as i ve read)

    • Offizieller Beitrag

    I just noticed that even if he installs flash plugin he ends up modifying a few lines in the /etc/fstab file which already pre-exists and someone could just edit it without installing the plug in. In conclusion to this issue I can;t understand the extra benefit of having this plug in installed if you end up modifying a file that already pre-exists and isnt been created by the flash plug in.

    The plugin never modifies fstab. It is just an optional step. Making fstab changes will NOT give you the benefits the plugin gives you. The plugin's only point is to configure folder2ram. folder2ram is what reduces the writes. folder2ram never modifies fstab either. I'm done trying to explain this. If you want to learn more, look at the code of the plugin and folder2ram.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    he mentioned the plugin being installed also made some other changes, and the fstab edits were just the final thing to make it all work together (I had the same theory as you, why not just add those options to fstab w/o installing the flash-memory plugin)

    I never wanted the plugin to edit fstab. It is dangerous for noobs and can cause the system not to boot. Plus, it does so little to reduce writes, it is very optional. If you have a swap file and are using it, yes it adds a lot of writes but the system also needs it. So, disabling swap is not the right answer to reduce writes.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • The plugin never modifies fstab. It is just an optional step. Making fstab changes will NOT give you the benefits the plugin gives you. The plugin's only point is to configure folder2ram. folder2ram is what reduces the writes. folder2ram never modifies fstab either. I'm done trying to explain this. If you want to learn more, look at the code of the plugin and folder2ram.

    Well thats a very different and wayyy better explanation here than the first one above few posts. Now besides you I m done asking about this because it makes more logical sense now than it did previously :P

  • Your recommendation intrigued me to search for it but didnt find adequate info to use it

    Please keep in mind what I've written: 'Only if you're really low on RAM you need to take care about your swap settings and then with an SSD I would immediately explore zswap' -- I doubt you're really low on RAM since an ordinary NAS can run with just 512 MB RAM without any swapping (Linux and filesharing daemons don't need much RAM, we're not running Chrome or Firefox with 40 open tabs on our NAS boxes).


    If you would need to think about swapping (very low RAM or you want to use a small Linux box as light desktop -- @ryecoaaron did you already purchase this nice new ARM toy?) then enabling zswap is a matter of running a sufficient kernel (Proxmox kernel from OMV Extras) and tweaking stuff accordingly: https://ubuntu-mate.community/…ncrease-performance/11302


    TL;DR: you don't need to spend time on zswap since you don't need to take care of swap anyway :)

    • Offizieller Beitrag

    Well thats a very different and wayyy better explanation here than the first one above few posts.

    It isn't better. It is more technical. I never know how technical to explain something. So, I normally lean toward simple.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    did you already purchase this nice new ARM toy?

    No, I'm trying to limit my arm board purchases lol

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • I doubt you're really low on RAM since an ordinary NAS can run with just 512 MB RAM without any swapping

    Correct. i use 8gb total just wanted to know the what if scenario.... thanks for explaining.



    we're not running Chrome or Firefox with 40 open tabs on our NAS boxes

    HAahahah...also true

    enabling zswap is a matter of running a sufficient kernel (Proxmox kernel from OMV Extras) and tweaking stuff accordingly: ubuntu-mate.community/t/enable…ncrease-performance/11302

    Thank you for the link

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!