Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #267670

Re: Orphaned Inode Problem

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

Show all headers | View raw


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


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