Problema allineamento HD/SSD con 4KiB fisici e 512B logici

[Mario Vanoni]

Valutando l'acquisto di nuova HW, ho scoperto
in inglese
https://ata.wiki.kernel.org/index.php/A ... tor_issues
e piu` aggiornato
http://www.ibm.com/developerworks/linux ... ml?ca=drs-
chiedo se qualcuno ha esperienza in merito in campo Linux.

[Mario Vanoni]

Preparatevi alla transizione, in inglese
http://www.hardwarecentral.com/hardware ... hp/3883801
un puro SSD invece, in inglese
http://www.newegg.com/Product/Product.a ... 6820227514
sicuramente i settori saranno 4KiB e non piu` 512B.

[Mario Vanoni]

Leggendo il seguente articolo, in inglese
http://www.linuxconfig.org/linux-wd-ear ... ced-format
pare che Linux non sia affatto pronto alla sfida.
Intriga questa riga

Codice: Seleziona tutto

In fact you can start partition by any number x where x >= 64 and is ^2. Thus 64, 128, 256, ... 2048 etc. For completeness I have also tested Advanced Format Hard Drive Utility for WindowsXP developed by Western Digital and this piece of software aligns a first partition to a 2048 sector.


Quindi M$ parte con 2048B per settore, Linux e` sempre fermo a 512B.

Non esperto nel partizionare HD, chiedo a chi ne sa` di piu`.
Come si sfruttano a pieno i settori 4096B del disco WD descritto?

[Mario Vanoni]

Altro punto di vista su
http://distrowatch.com/weekly.php?issue=20100628
riporto l'articolo per intero

TRIM on solid state drives (SSD)

Keeping-things-TRIM asks: I've heard that without TRIM SSD performance will degrade over time. TRIM is now supported in some SSD firmware, and recently has been enhanced to support RAID systems. But TRIM does not work without OS support. Some TRIM support is available in the Linux kernel, but people are having trouble figuring out what is going on. So what's happening with TRIM?

DistroWatch answers: The issues facing solid state drives (SSD) and TRIM can be a little difficult to explain, but I'll try to give a quick overview here. Hard drives tend to be fairly dumb devices as far as hardware goes. So, traditionally, when an operating system decides to delete a file, it removes references to that file rather than telling the hard disk that the data should be removed. This is a bit like going to a library and destroying a book's index card without actually removing the physical book from the library. This means that, in some cases, it's possible to get your data back after a file has been deleted by carefully searching through the physical drive. Trying to find the contents of a deleted file is a little like searching through an entire library looking for a book which no longer has an index card.

Treating the hard disk as being dumb has worked fairly well for us up to this point because it means the operating system can keep track of things while the disk simply reads or writes to certain areas without concerning itself with what was there before. To a traditional hard disk, over-writing existing data isn't really any different than writing to a blank part of the disk. But then solid state drives came along and they work a little differently. To an SSD, over-writing data is different (and slower) than simply writing to a blank area of the drive. Much the same way it takes longer for a person to erase a chalk board before writing something new.

The problem is that if the operating system is still treating the SSD as a dumb device, the drive doesn't know which parts of its storage have been used before (and can now be erased). This is where TRIM comes in. It's a way for the operating system to bring the solid state drive up to speed on which blocks aren't in use and can be wiped. This way the SSD can perform house cleaning and we don't run into cases where the drive is trying to wipe data immediately prior to writing.

Now that the Linux kernel has TRIM support, this should all fade into the background, right? Almost. Except in cases where the feature has been backported, only the most recent kernels (2.6.33 and above) have TRIM support. Likewise, I think FreeBSD users will have to wait for FreeBSD 9.0 to get the same feature. Linux users who are on older kernels can get TRIM support via a program called hdparm. The hdparm program (versions 9.17 and up) will search for free blocks in the file system and let the SSD know which areas should be cleaned. If your distribution doesn't supply a recent release of hdparm, you can get a copy from here.

So now we have kernel support and, as a backup, hdparm, so we're covered? Almost. Older SSDs may not support TRIM commands. In those cases, you'll either need to get updated firmware for the SSD or buy a newer drive. When in doubt, check with the manufacturer to see if your device supports TRIM and, if it does not, ask if the device can be upgraded.

Questa nuova tecnologia non e` ancora entrata nella mente Linux,
per chi compera una macchina nuova con solo SSD?

[slux]

Ciao Mario,
ho 2 hd wd da 1Tb proprio con questa nuova features dei blocchi a 4kb.Essendo abbastanza ignorante ho semplicemente impostato il jumper dei 2 dischi in modalità legacy, diciamo così, e vado molto bene con le prestazioni.Ho punte di quasi 100Mb/s (hdparm -t ), per quanto può valere questo test comunque sia.
Una domanda da completo ignorante,ma l'opzione -b di mke2fs o -I(inode size),non aiuta ?

[Mario Vanoni]

Ciao Mario,
ho 2 hd wd da 1Tb proprio con questa nuova features dei blocchi a 4kb.Essendo abbastanza ignorante ho semplicemente impostato il jumper dei 2 dischi in modalità legacy, diciamo così, e vado molto bene con le prestazioni.Ho punte di quasi 100Mb/s (hdparm -t ), per quanto può valere questo test comunque sia.
Una domanda da completo ignorante,ma l'opzione -b di mke2fs o -I(inode size),non aiuta ?

Ho due macchine ognuna con due HD da 1TB, IBM/Hitachi di 3/4/anni fa`,
ovviamente con settori originali di 512B.
hdparm -t /dev/... dice per tutti e quattro HD 82.[67]? MB/sec
Quindi con il jumper legacy non sfrutti i settori presenti di 4096B,
ma obblighi la SW del disco a dividere ogni settore presente in 8 settori fittivi.
Ti funziona, OK, il problema e` il primo settore,
li` Linux ha difficolta` se non e` 512B, certi loader ignorano 513...4096B,
altri, anche BSD, vanno in TILT, problema non risolto in mondo Linux.

Uso da sempre mkfs.ext2 -b 4096 -i 4096 per i dischi,
non aiuta per HD/SSD con settori di 4096B, Linux pensa sempre in settori 512B!

[Trotto@81]

Stavo meditando di prenderne uno, ma vedo che Linux in questo settore è rimasto al paleolitico.
Mi serviva giusto per il sistema operativo, poi magari fra 4/5 anni quando costi e prestazioni saranno migliori l'avrei cambiato.

[Naitso]

io ho risolto così, come indicato nella guida IBM

Codice: Seleziona tutto

fdisk -H 224 -S 56 /dev/sdX

però lo uso in NAS esterno, dunque solo per archiviazione dati

[Trotto@81]

Risolve il problema consentendo di installarci anche un bootloader?
Come mai lo usi per archiviazione dati?
Da quello che ho letto in giro è proprio sconsigliato per questo tipo di utilizzo.

[Naitso]

Risolve il problema consentendo di installarci anche un bootloader?
Come mai lo usi per archiviazione dati?
Da quello che ho letto in giro è proprio sconsigliato per questo tipo di utilizzo.

1. I dischi sono installati in un NAS dunque non so per il bootloader, ma allineando le partizioni penso proprio che non ci siano problemi.
2. Un HD a cosa serve?
3. Sconsigliato? e perché dato che questa soluzione prende sempre più piede fra i produttori di HD?

P.S. so poco nulla, non sono un informatico, ma seguendo la guida di IBM nel mio caso funziona, e al comando fdisk -l non appaiono più messaggi di avviso di più non so...

[Trotto@81]

Si usurano molto in fretta, è bene ridurre al minimo le operazioni di lettura e scrittura, la tecnologia sta prendendo piede, ma non è affidabile come i classici hdd.
Ecco perchè si consiglia di non usarlo come storage, per evitare di minare l'integrità dei dati, e se ci pensi bene, che te ne fai della velocità di accesso su un disco storage?

[erio]

è da un po che girano schede pci con vari tagli di storage,l'hard disk tipico andra sicuramente in pensione....ma non per ora,le schede pci tecnologia ssd arrivano a due terabite,sono costose,e credo per un bel pezzo.ma l'integrita dei dati è garantita.

[Trotto@81]

è da un po che girano schede pci con vari tagli di storage,l'hard disk tipico andra sicuramente in pensione....ma non per ora,le schede pci tecnologia ssd arrivano a due terabite,sono costose,e credo per un bel pezzo.ma l'integrita dei dati è garantita.

Cerco un datasheet e lo post, giusto per avere un riscontro e non parlare a casaccio.
http://www.supertalent.com/datasheets/6_132.pdf
SSD con cella di tipo MLC, quindi vale per qualsiasi dispositivo con tale cella.

Codice: Seleziona tutto

8GB          4.38 yrs @50GB write-erase/day
15GB         8.22 yrs @ 50GB write-erase/day
30GB         16.44 yrs @ 50GB write-erase/day
60GB         32.88 yrs @ 50GB write-erase/day
120GB        65.75 yrs @ 50GB write-erase/da


La durata è strettamente legata alla quantità di dati letti e scritti ogni giorno.

[Naitso]

Si usurano molto in fretta, è bene ridurre al minimo le operazioni di lettura e scrittura, la tecnologia sta prendendo piede, ma non è affidabile come i classici hdd.
Ecco perchè si consiglia di non usarlo come storage, per evitare di minare l'integrità dei dati, e se ci pensi bene, che te ne fai della velocità di accesso su un disco storage?

Scusa Trotto@81, tu parli di SSD, io di HD normali, dove in quelli di recente costruzione c'è lo stesso problema citato da Mario 4096 fisici e 512B logici....

CIao

[Trotto@81]

Tranquillo, ero comunque io off topic.