Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #267670
| From | Gremlin <scott-andrews@columbus.rr.com> |
|---|---|
| Newsgroups | linux.debian.user |
| Subject | Re: Orphaned Inode Problem |
| Date | 2024-02-21 22:40 +0100 |
| Message-ID | <Ia2tP-bIsR-11@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <I9drj-bdO4-1@gated-at.bofh.it> <I9fCO-bf0J-3@gated-at.bofh.it> <I9fMt-bf3P-3@gated-at.bofh.it> <I9SEa-bCKy-11@gated-at.bofh.it> <I9Zmh-bGHn-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 2/21/24 13:14, David Christensen wrote: > On 2/21/24 03:00, Jörg-Volker Peetz wrote: >> Hi, >> >> did you take a look at the smartctl output? >> >> Somewhere I read, for maintainance of an SSD all it's cells should be >> read from time to time like this >> >> sudo dd if=/dev/DEVICE of=/dev/null bs=8M status=progress >> >> where device is something like sda or nvme0n1, especially if it was >> switched off for a longer period. At least, it shows the current read >> performance of the device. >> An SSD should regularly be trimmed, if in use. This is to assist it's >> wear leveling process. >> >> What's your opinion? >> >> Regards, >> Jörg. > > > I prefer to run a SMART long test periodically. This should read every > cell, including those that are reserved and not visible to the OS. > > > AIUI So long as the SSD can maintain a supply of erased cells via > manufacturer over-provisioning, trim is not required to maintain > performance. If you have workload that does a lot of writes in a short > period of time and exhausts the manufacturer over-provisioning, leaving > free space on the SSD and trimming can be a work-around. > > > If you are using strong encryption, not trimming will leave crypttext on > disk that creates more work for an attacker. If you are using weak > encryption, not trimming will leave crypttext on disk that an attacker > can recover. > > > For imaging/ cloning, trimming will zero blocks freed by the OS and > facilitate compression of the image file. > > > I have a SOHO network with about two dozen disks. Running smartctl by > hand is a PITA. Running fstrim(8) by hand is easy enough. I try to do > both once a month. I need to figure out smartd(8). > > > David > #!/usr/bin/dash - drives="$(lsblk|grep '^sd')" for i in $drives;do case $i in sd*) sudo smartctl -a /dev/"$i" ;; *) : ;; esac done
Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Orphaned Inode Problem "Stephen P. Molnar" <s.molnar@sbcglobal.net> - 2024-02-19 16:10 +0100
Re: Orphaned Inode Problem <tomas@tuxteam.de> - 2024-02-19 18:30 +0100
Re: Orphaned Inode Problem "Stephen P. Molnar" <s.molnar@sbcglobal.net> - 2024-02-19 18:40 +0100
Re: Orphaned Inode Problem <tomas@tuxteam.de> - 2024-02-19 18:50 +0100
Re: Orphaned Inode Problem Jörg-Volker Peetz <jvpeetz@web.de> - 2024-02-21 12:10 +0100
Re: Orphaned Inode Problem Henning Follmann <hfollmann@itcfollmann.com> - 2024-02-21 14:20 +0100
Re: Orphaned Inode Problem Jörg-Volker Peetz <jvpeetz@web.de> - 2024-02-21 17:20 +0100
Re: Orphaned Inode Problem <tomas@tuxteam.de> - 2024-02-22 07:10 +0100
Re: Orphaned Inode Problem Henning Follmann <hfollmann@itcfollmann.com> - 2024-02-22 08:50 +0100
Re: Orphaned Inode Problem Jörg-Volker Peetz <jvpeetz@web.de> - 2024-02-22 11:30 +0100
Re: Orphaned Inode Problem gene heskett <gheskett@shentel.net> - 2024-02-22 05:30 +0100
Re: Orphaned Inode Problem David Christensen <dpchrist@holgerdanske.com> - 2024-02-21 19:20 +0100
Re: Orphaned Inode Problem Gremlin <scott-andrews@columbus.rr.com> - 2024-02-21 22:40 +0100
Re: Orphaned Inode Problem Eike Lantzsch ZP5CGE / KY4PZ <zp6cge@gmx.net> - 2024-02-19 20:20 +0100
red SATA cables "notoriously bad"? (Was Re: Orphaned Inode Problem) Andy Smith <andy@strugglers.net> - 2024-02-20 01:50 +0100
Re: red SATA cables "notoriously bad"? Felix Miata <mrmazda@earthlink.net> - 2024-02-20 02:20 +0100
Re: red SATA cables "notoriously bad"? Andy Smith <andy@strugglers.net> - 2024-02-20 02:30 +0100
Re: red SATA cables "notoriously bad"? Felix Miata <mrmazda@earthlink.net> - 2024-02-20 03:10 +0100
Re: red SATA cables "notoriously bad"? David Christensen <dpchrist@holgerdanske.com> - 2024-02-20 10:30 +0100
Re: red SATA cables "notoriously bad"? gene heskett <gheskett@shentel.net> - 2024-02-20 14:50 +0100
Re: red SATA cables "notoriously bad"? gene heskett <gheskett@shentel.net> - 2024-02-20 04:10 +0100
Re: red SATA cables "notoriously bad"? Andy Smith <andy@strugglers.net> - 2024-02-20 04:20 +0100
Re: red SATA cables "notoriously bad"? gene heskett <gheskett@shentel.net> - 2024-02-20 04:40 +0100
Re: red SATA cables "notoriously bad"? (Was Re: Orphaned Inode Problem) gene heskett <gheskett@shentel.net> - 2024-02-20 03:40 +0100
Re: red SATA cables "notoriously bad"? (Was Re: Orphaned Inode Problem) jeremy ardley <jeremy.ardley@gmail.com> - 2024-02-20 04:40 +0100
Re: red SATA cables "notoriously bad"? (Was Re: Orphaned Inode Problem) Eike Lantzsch ZP5CGE / KY4PZ <zp6cge@gmx.net> - 2024-02-20 11:00 +0100
Re: red SATA cables "notoriously bad"? (Was Re: Orphaned Inode Problem) Eike Lantzsch ZP5CGE / KY4PZ <zp6cge@gmx.net> - 2024-02-20 11:20 +0100
csiph-web