Problema HDD SSD trim - mount - umount

8 views
Skip to first unread message

Sabin Lucea

unread,
Jan 12, 2015, 1:52:43 PM1/12/15
to ar...@googlegroups.com
Buna seara

Ma confrunt de ceva vreme cu o problema.

Pe un server stabil , productie, cu 2xIntel(R) Xeon(R) CPU E5620  @ 2.40GHz si 32GB Ram avand ubuntu12.04 / 64 se adauga un controler cu 2 SSD -uri 1 TB raid 1 mirror pe care se va dori a se stoca tabele mysql. Creez partitia lvm de test .

root@hpserver:~# uname -a
Linux hpserver 3.2.0-70-generic #105-Ubuntu SMP Wed Sep 24 19:49:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

root@hpserver:~#  hdparm -I /dev/sda | grep "TRIM"
           *    Data Set Management TRIM supported (limit unknown)

pvcreate /dev/sda
vgcreate VG-SSD /dev/sda
lvcreate -L 100G -n Partitie1_tmp_SSD VG-SSD

root@hpserver:~# mkfs.ext4 /dev/VG-SSD/Partitie1_tmp_SSD
mke2fs 1.42 (29-Nov-2011)
Discarding device blocks: done
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
6553600 inodes, 26214400 blocks
1310720 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
800 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

Dupa dupa ce fac mount , pot folosi systemul de fisiere de pe SSD .

root@hpserver:~# mount /dev/VG-SSD/Partitie1_tmp_SSD /mnt/SSD_tmp/
root@hpserver:~# mkdir /mnt/SSD_tmp/test_ssd
root@hpserver:~# ls -la /mnt/SSD_tmp/
total 28
drwxr-xr-x 4 root root  4096 Jan 12 18:50 .
drwxr-xr-x 6 root root  4096 Jan 12 14:55 ..
drwx------ 2 root root 16384 Jan 12 18:41 lost+found
drwxr-xr-x 2 root root  4096 Jan 12 18:50 test_ssd

Uneori imediat , alteori mai tarziu, cand execut trim si umount / mount de cateva ori apare un fenomen,  sistemul de fisiere se corupe , nu se mai vede nici macar folderul de lost+found.
 df -h imi arata partitia montata si faptul ca am date pe ea, insa nu mai pot accesa acele datele si nu mai pot scrie nimic

root@hpserver:~# ls -la /mnt/SSD_tmp/
total 0
root@hpserver:~# mkdir /mnt/SSD_tmp/test_ssd3
mkdir: cannot create directory `/mnt/SSD_tmp/test_ssd3': Input/output error
root@hpserver:~# fstrim -v /mnt/SSD_tmp
/mnt/SSD_tmp: 105492676608 bytes were trimmed
root@hpserver:~# ls -la /mnt/SSD_tmp/
total 0
root@hpserver:~# umount /mnt/SSD_tmp/
root@hpserver:~# mount /dev/VG-SSD/Partitie1_tmp_SSD /mnt/SSD_tmp/
root@hpserver:~# ls -la /mnt/SSD_tmp/
total 0
root@hpserver:~# mkdir /mnt/SSD_tmp/test_ssd3
mkdir: cannot create directory `/mnt/SSD_tmp/test_ssd3': Input/output error
root@hpserver:~# fstrim -v /mnt/SSD_tmp
/mnt/SSD_tmp: 105492676608 bytes were trimmed
root@hpserver:~# fstrim -v /mnt/SSD_tmp
/mnt/SSD_tmp: 0 bytes were trimmed
root@hpserver:~# fstrim -v /mnt/SSD_tmp
/mnt/SSD_tmp: 0 bytes were trimmed
root@hpserver:~# mkdir /mnt/SSD_tmp/test_ssd3
mkdir: cannot create directory `/mnt/SSD_tmp/test_ssd3': Input/output error
root@hpserver:~# fstrim -v /mnt/SSD_tmp
/mnt/SSD_tmp: 0 bytes were trimmed
root@hpserver:~# umount /mnt/SSD_tmp/

Nu am idee ce produce acest fenomen , sa fie problema la SSD  , sau soft cumva si e legat de trim. Am folosit intens si copiat fara probleme cantitati destul de mari de date , tabele actuale mysql sunt de 30 Gb si urmeaza sa creasca , in mod normal echipamentul ramane pornit tot timpul , insa am avut curiozitatea sa vad ce se intampla dupa mai multe mount / umount / trim si nu mi-a placut deloc sa nu pot accesa datele. Sistemul actual de operare nu se poate schimba momentan. Curios este ca am incercat si cu mai multe partitii lvm, prima partitie in general ramane in stare de functionare , in timp ce restul se corup

Va multumesc pentru atentie , astept cu interes orice idee, sugestie , solutie !

Alin Crețu

unread,
Jan 12, 2015, 2:34:04 PM1/12/15
to ar...@googlegroups.com
Salut,

Output-ul care l-ai dat ca exemplu arata ca tu faci un filesystem doar pe un sigur disk (sda) si nu pe o matrice RAID.
Ce fel de controller (marca/model) ai acolo in care bagi cele doua SSD-uri ?
Ce fel de SSD-uri (marca/model) folosesti ?

Faptul ca faci RAID 1 pe cele doua discuri imi da de inteles ca vrei sa ai copii redundante la date in cazul unui defect hardware la sistemul de stocare de date.
Ai legat/conectat ambele copii ale RAID-ului pe acelasi controller ?


Alin Crețu


--
--
Aţi primit acest mesaj pentru că sunteţi abonat la Grupul Google "Arad
Linux Users Group".
Pentru a posta în acest grup, trimiteţi e-mail la ar...@googlegroups.com
Pentru a vă dezabona de la acest grup, trimiteţi un e-mail la
arlug+un...@googlegroups.com
Pentru mai multe opţiuni, vizitaţi acest grup la
http://groups.google.com/group/arlug?hl=ro
---
Ați primit acest mesaj deoarece sunteți abonat(ă) la grupul „Arad Linux Users Group” din Grupuri Google.
Pentru a vă dezabona de la acest grup și pentru a nu mai primi e-mailuri de la acesta, trimiteți un e-mail la adresa arlug+un...@googlegroups.com.
Pentru mai multe opțiuni, accesați https://groups.google.com/d/optout.

Sabin Lucea

unread,
Jan 12, 2015, 3:41:04 PM1/12/15
to ar...@googlegroups.com
Hdd-urile sunt samsung. Se vede /dev/sda pt ca este raid hard . Clar sunt conectate ambele
Cand nu foloseam controlerul aparea in sistemin felul urmator

fdisk /dev/cciss/c0d0
fdisk /dev/cciss/c0d1
pvscan
vgscan
fdisk /dev/cciss/c0d1
fdisk -l
fdisk /dev/cciss/c0d1
fdisk -l
pvcreate /dev/cciss/c0d1p1
pvcreate /dev/cciss/c0d1p2
 


Alin Crețu

unread,
Jan 12, 2015, 3:49:37 PM1/12/15
to ar...@googlegroups.com


Ce fel de controller este ? Marca/Model.
Inainte sa-l infigi in slot si discurile in el, ai verificat daca stie ce sa faca cu comenzile TRIM (daca are suport pentru TRIM sau nu).


Incearca sa-l scoti din schema (sa conectezi discurile pe alte porturi decit cele de pe controller) si apoi verifica daca ti se reproduce problema.





Alin Crețu

unread,
Jan 12, 2015, 4:06:31 PM1/12/15
to ar...@googlegroups.com


Ce fel de controller este ? Marca/Model.


Inainte sa-l infigi in slot si discurile in el, ai verificat daca stie ce sa faca cu comenzile TRIM (daca are suport pentru TRIM sau nu).






Sabin Lucea

unread,
Jan 12, 2015, 4:09:28 PM1/12/15
to ar...@googlegroups.com
Mda, posibil sa se agate ceva la controller dar atunci nu ar trebui sa fie o chetiune mai categorica ? Daca nu fac umount si fstrim repetat , datele sunt acolo timp de 7-10 zile

Nu stiu acuma exact modelul de controler  dar a fost controlerul recomandat de furnizorul de echipament pentru cele 2 HDD-uri ca sa suporte raid hard. Nu stiu unde se puteau verifica comezile fstrim-trim legate de controler. in afara de


root@hpserver:~#  hdparm -I /dev/sda | grep "TRIM"
           *    Data Set Management TRIM supported (limit unknown)

Am presupus ca daca rezultatul cel de mai sus si kernel este >2.6.3x.x ( in cazul meu 3.2.0-70-generic ) este totul ok

 Fiind achizitionate acuma de aprox 2 luni , si chiar au costat ceva ,  nu prea cred  ca nu  sunt impementate, dar cine stie ... o fi undeva ceva ca de aia da cu virgula :P


Alin Crețu

unread,
Jan 12, 2015, 4:27:36 PM1/12/15
to ar...@googlegroups.com

man page-ul de la fstrim zice ca fstrim se foloseste pe filesystem montat.


Sabin Lucea

unread,
Jan 12, 2015, 4:31:51 PM1/12/15
to ar...@googlegroups.com
da , fstrim il folosesc din cron pe sistemul montat, ideea era sa simulez eventuale cazuri de intreruperi acidentale de curent  sau reboot. Am avut si surpriza neplacuta ca dupa primul fstrim si umount sau mu mai pot accesa datele :(

Sabin Lucea

unread,
Jan 13, 2015, 1:46:27 AM1/13/15
to ar...@googlegroups.com
Revin cu o precizare .
Pe un alt sistem care este tot in productie insa pe care nu am avut surprize

root@serv:~# hdparm -I /dev/sda | grep "TRIM"
           *    Data Set Management TRIM supported (limit 1 block)
           *    Deterministic read data after TRIM

Ar putea sa provina inconsistenta de aici , deoarece pe sistemul problema rezultatul este doar :


root@hpserver:~# hdparm -I /dev/sda | grep "TRIM"
           *    Data Set Management TRIM supported (limit unknown)

Sabin Lucea

unread,
Jan 13, 2015, 2:13:11 AM1/13/15
to ar...@googlegroups.com
se pare ca aici este problema , pe controller https://wiki.archlinux.org/index.php/Talk:Solid_State_Drives

mai exact ce au constatat si altii

Verify Trim Support section ambiguous

This section implies that only the following results confirm that the drive has TRIM support:

       *    Data Set Management TRIM supported (limit 1 block)
       *    Deterministic read data after TRIM

My result when I run the command # hdparm -I /dev/sda | grep TRIM is as follows:

       *    Data Set Management TRIM supported (limit unknown)

I will assume that the lack of "Deterministic read data after TRIM" in my results is not a problem, and that my drive does support TRIM. If that's correct, shall we remove the unecessary line from the example? Either way, we should clarify what results are key to arriving at the conclusion that the drive does or does not support TRIM so there is as little ambiguity as possible. Lightnin (talk) 20:16, 2 June 2014 (UTC)


Reply all
Reply to author
Forward
0 new messages