I server di Google migrano su EXT4.

[Mario Vanoni]

Mario, tu però usi EXT2 e sai benissimo cosa succede se avviene un blackout senza che sia presente un UPS; non essendo un FS di tipo journal, al successivo riavvio parte e2fsck e buonanotte ai dati che avevi sul disco.

Si`, ma un e2fsck ogni 100 boot (tune2fs) non mi disturba piu` di tanto,
anche perche' ogni tanto, per errore mio, devo spegnere una macchina,
in modo cattivo, quindi interruttore della corrente.
Ovviamente ho un UPS, qui a Cuasso la ENEL ha sbalzi immensi,
in piu` spesso interruzioni cosi`a caso di 1-2 minuti,
controllo con crontab la tensione che misura apcupsd ogni minuto,
in un anno ha variato da 188V a 238V, sulla bolletta dicono 220V.

Quello che non mi piace in ext4 e`

Ext4 increases performance by using delayed allocation which delays the block allocation until the data is ready to be written to disk. This process improves allocation decisions by the operating system as it knows exactly the file size before being allocated.

significa che legge prima i dati per sapere la dimensione finale del file,
prima di scriverlo sul disco, con un file immenso lo perdi se c'e` errore.

Con ext2 almeno ti ritrovi frammenti in /lost+found dopo un e2fsck.

[shark1500]

significa che legge prima i dati per sapere la dimensione finale del file,
prima di scriverlo sul disco, con un file immenso lo perdi se c'e` errore.

No, invece che scrivere sempre (e far diventare l'hd un formaggio coi buchi) scrive ogni meno secondi, in questo modo riesce a scrivere piu` roba insieme a blocchi piu` grandi, quindi ottimizza le scritture su disco (che tutti sappiamo sono molto delicate) ma come contro ha che se ti muore la macchina in quel periodo li` hai perso i dati (tipo i dati dell'ultimo minuto).

[Mario Vanoni]

significa che legge prima i dati per sapere la dimensione finale del file,
prima di scriverlo sul disco, con un file immenso lo perdi se c'e` errore.

No, invece che scrivere sempre (e far diventare l'hd un formaggio coi buchi) scrive ogni meno secondi, in questo modo riesce a scrivere piu` roba insieme a blocchi piu` grandi, quindi ottimizza le scritture su disco (che tutti sappiamo sono molto delicate) ma come contro ha che se ti muore la macchina in quel periodo li` hai perso i dati (tipo i dati dell'ultimo minuto).

Ext4 increases performance by using delayed allocation which delays the block allocation until the data is ready to be written to disk.

Lo traduco/interpreto in modo differente ...
Metti un file di 1GB, lo scrive solo quando ha allocato/trovato
sufficienti blocchi vicini per scriverlo in una volta sola.
Se sfogliando meta` HD non trova blocchi contigui,
continuera` finche' li trova!
Con un HD, sono tutti lenti in confronto al resto della HW,
in questo spazio di tempo tutto rimane possibile!

[shark1500]

No, non e` cosi`, non so dove hai letto quella roba li` (non ho visto la fonte), ma facendo la tua ipotesi, se devi scrivere un file da 1GB aspetta (metti che scrive ogni 60sec), e poi li scrive il piu` contigui possibile.

Aspettando riduce di molto la frammentazione del disco, e quindi aumenta le prestazioni.

Ad ogni modo se non ti piace questa cosa basta montare la partizione con "nodelalloc" e torni come prima.

[Mario Vanoni]

No, non e` cosi`, non so dove hai letto quella roba li` (non ho visto la fonte), ma facendo la tua ipotesi, se devi scrivere un file da 1GB aspetta (metti che scrive ogni 60sec), e poi li scrive il piu` contigui possibile.

Aspettando riduce di molto la frammentazione del disco, e quindi aumenta le prestazioni.

Ad ogni modo se non ti piace questa cosa basta montare la partizione con "nodelalloc" e torni come prima.

a) fonte originale
http://www.beginlinux.com/server_traini ... -on-ubuntu

b) concordo se non capitano errori, perche' secondo
http://lwn.net/Articles/317787/

Akira's patch addresses these problems with the creation of a new, magic ioctl() call for ext4. The defragmentation application must fill out a structure like:

struct move_extent {
int org_fd; /* original file descriptor */
int dest_fd; /* destination file descriptor */
ext4_lblk_t start; /* logical offset of org_fd and dest_fd*/
ext4_lblk_t len; /* exchange block length */
};

This structure, when passed to the new EXT4_IOC_DEFRAG ioctl(), expresses a request to the kernel to move len blocks from the original file to the new one, starting at start. Essentially, it copies an extent's worth of data into the (fully allocated, nicely contiguous) space in the new file, then performs a magic block swap. The contiguous blocks from the new file are patched into the old file, while the fragmented blocks are, instead, put into the new file. Once the entire file has been treated in this way, the file will have been defragmented without having been visibly moved.

The final step is to delete the "new" file, which now contains the "old" file's blocks. Since the file had been unlinked, that will cause the filesystem to recover the old blocks and the task will be complete. For the curious, Akira has posted the source for a user-space defragmentation tool which shows how this interface can be used.

anche qui non parlano di 60 secondi parziali, ma del file completato in una volta sola!

Che giovi ridurre la frammentazione OK, ma perdere un file grande con un errore di 1 secondo ...
Poi leggendo meglio, con ext4 impieghi piu` tempo a scrivere questo file grande sul disco.

[conraid]

Ma Mario, la "Online defragmentation" è cosa diversa da "Delayed allocation" che è quella messa in discussione (che tra l'altra hanno anche altri "moderni" filesystem)

per ext4
http://ext4.wiki.kernel.org/index.php/Main_Page

che per una introduzione rimanda a
http://kernelnewbies.org/Ext4

che poi ci siano svantaggi è naturale purtroppo, ma il problema che venne evidenziato a suo tempo fu risolto se non erro.
Ora dovrebbe essere meno "fallimentare", ma non totalmente visto il meccanismo con cui opera

Tra l'altro io ho capito che Google ha assunto il creatore di ext4 proprio per lavorarci e migliorare il filesystem

UPDATE
qui l'inizio della discussione sul problema
https://bugs.edge.launchpad.net/ubuntu/ ... bug/317781
ma a quanto sapevo il "bug" fu risolto, a scapito delle prestazioni, che poi il "progetto" abbia punti che non piacciono è altro discorso
ma qui parlo da ignorante

[Mario Vanoni]

Ma Mario, la "Online defragmentation" è cosa diversa da "Delayed allocation" che è quella messa in discussione (che tra l'altra hanno anche altri "moderni" filesystem)

per ext4
http://ext4.wiki.kernel.org/index.php/Main_Page

che per una introduzione rimanda a
http://kernelnewbies.org/Ext4

che poi ci siano svantaggi è naturale purtroppo, ma il problema che venne evidenziato a suo tempo fu risolto se non erro.
Ora dovrebbe essere meno "fallimentare", ma non totalmente visto il meccanismo con cui opera

Tra l'altro io ho capito che Google ha assunto il creatore di ext4 proprio per lavorarci e migliorare il filesystem

Dal tuo primo articolo citato

2.10. Online defragmentation

(This feature is being developed and will be included in future releases). While delayed allocation, extents and multiblock allocation help to reduce the fragmentation, with usage filesystems can still fragment. For example: You write three files in a directory and continually on the disk. Some day you need to update the file of the middle, but the updated file has grown a bit, so there's not enough room for it. You have no option but fragment the excess of data to another place of the disk, which will cause a seek, or allocate the updated file continually in another place, far from the other two files, resulting in seeks if an application needs to read all the files on a directory (say, a file manager doing thumbnails on a directory full of images). Besides, the filesystem can only care about certain types of fragmentation, it can't know, for example, that it must keep all the boot-related files contiguous, because it doesn't know which files are boot-related. To solve this issue, Ext4 will support online fragmentation, and there's a e4defrag tool which can defragment individual files or the whole filesystem.

Questo non e` ancora presente,
ma mi fa venire seri dubbi sulla sua affidabilta`, mi spiego:

HD vecchi, Hitachi/IBM da 1 TB hanno una memoria on-board di 32MB.
La loro logica integrata decide _quando_ scrivere i dati ricevuti,
non e` il FS o il SO che decide, alla merce' del produttore HD.
Quelli nuovi da 2 TB ecc. addirittura 64MB o 128MB on-board.

Ricordo di oltre 20 anni fa:
HD erano solo SCSI con UNIX,
la loro misera cache (8-16kB) == on-board memory di oggi
si poteva disattivare senza problemi.
In una ditta amica il capo non amava cache attivi sugli HD,
voleva che i dati fossero trasferiti all'istante!

Oggi come oggi mi sembra un po` un circolo vizioso,
SW molto intelligente che combatte HW molto potente.

[conraid]

HD vecchi, Hitachi/IBM da 1 TB hanno una memoria on-board di 32MB.
La loro logica integrata decide _quando_ scrivere i dati ricevuti,
non e` il FS o il SO che decide, alla merce' del produttore HD.
Quelli nuovi da 2 TB ecc. addirittura 64MB o 128MB on-board.

Tralascio il "vecchi" per HD da 1TB, ma qui siamo alle solite
mi spiego

scoperto il bug cosa dice lo sviluppatore?
E' colpa di chi scrive le applicazioni che non prevede un metodo di scrittura dei dati ma lascia il compito di decidere il momento al filesystem. La risposta ovvia è "ci devi pensare tu, noi diciamo di scrivere e che ne sappiamo cosa c'è sotto?"
Può esserci ext4 come ext2 o fat, è il kernel che con i driver del filesystem dovrebbe occuparsi di questo.
Ora tu dici che nemmeno OS/FS devono farlo, ma il produttore di dischi. Ma anche qui converrai che se io ho un altro HD che si comporta in modo diverso che succede?
Secondo me è il kernel che deve occuparsene.
Ma ripeto, sono nulla in questo ambito, parlo solo per intuizioni, magari sbagliate

[Mario Vanoni]

HD vecchi, Hitachi/IBM da 1 TB hanno una memoria on-board di 32MB.
La loro logica integrata decide _quando_ scrivere i dati ricevuti,
non e` il FS o il SO che decide, alla merce' del produttore HD.
Quelli nuovi da 2 TB ecc. addirittura 64MB o 128MB on-board.

Tralascio il "vecchi" per HD da 1TB, ma qui siamo alle solite
mi spiego

scoperto il bug cosa dice lo sviluppatore?
E' colpa di chi scrive le applicazioni che non prevede un metodo di scrittura dei dati ma lascia il compito di decidere il momento al filesystem. La risposta ovvia è "ci devi pensare tu, noi diciamo di scrivere e che ne sappiamo cosa c'è sotto?"
Può esserci ext4 come ext2 o fat, è il kernel che con i driver del filesystem dovrebbe occuparsi di questo.
Ora tu dici che nemmeno OS/FS devono farlo, ma il produttore di dischi. Ma anche qui converrai che se io ho un altro HD che si comporta in modo diverso che succede?
Secondo me è il kernel che deve occuparsene.
Ma ripeto, sono nulla in questo ambito, parlo solo per intuizioni, magari sbagliate

Sei all merce' dei costruttori HW. mi spiego:
ogni giorno registro le temperature in casa e fuori, da tre anni.
File flat scritto con [n]vi(1),
dopo l'abituale :wq osservo che il LED per HD non fa niente,
per un file di circa 40kB la logica disco non si muove.
Magari dopo mezz'ora sento il disco muoversi ed il LED da un lampo.
Non so quanto sia il timing del disco, in ogni caso non in tempo reale!
E qui non servono i geni dei FS o del SO, arrendersi all'evidenza,
oramai molti cose sono decise (in bene o male) dalla HW che hai.

[shark1500]

Qua stiamo andando _totalmente_ fuori argomento. Per quanto riguarda i dischi quando il kernel scrive, il disco gli risponde "ho scritto" (anche se poi e` in cache o poi lo scrive dopo svariato tempo). Questo e` un problema noto sia dal fs che da tante altri componenti (non per ultima lo scheduler del disco), ma ripeto: non c'entra niente.

Tornando ad ext4 leggi linux/Documentation/filesystem/ext4.txt , e scoprirai che tutte queste cose che non ti piacciono si possono disabilitare come vuoi, basta dirglielo quando monti il disco (e magari google usa alcuni di questi parametri).

[Mario Vanoni]

Qua stiamo andando _totalmente_ fuori argomento. Per quanto riguarda i dischi quando il kernel scrive, il disco gli risponde "ho scritto" (anche se poi e` in cache o poi lo scrive dopo svariato tempo). Questo e` un problema noto sia dal fs che da tante altri componenti (non per ultima lo scheduler del disco), ma ripeto: non c'entra niente.

Tornando ad ext4 leggi linux/Documentation/filesystem/ext4.txt , e scoprirai che tutte queste cose che non ti piacciono si possono disabilitare come vuoi, basta dirglielo quando monti il disco (e magari google usa alcuni di questi parametri).

Ho letto ext4.txt gia` prima, IMVHO se Google lo usa
perche' ha abbastanza HD grandi e tante UPS,
poi tante macchine ridondanti e potenti,
quindi a loro ext4 fa comodo al posto di ext2.

Ma quale utente privato non ci guadagni niente,
tranne lo e2fsck periodico che (forse) eviti.

[shark1500]

Ma quale utente privato non ci guadagni niente,
tranne lo e2fsck periodico che (forse) eviti.

Come no se ci guadagni. Scrivendo di meno sul disco significa fare meno accessi, e significa che il disco dura di piu`, che viene usato di meno (= piu` batteria sui portatili) e che va piu` veloce.

Tutti questi test sono stati abbondantemente verificati (personalmente e anche su vari siti) e anche la non perdita dei dati e` stata verificata.

[Mario Vanoni]

Ma quale utente privato non ci guadagni niente,
tranne lo e2fsck periodico che (forse) eviti.

Come no se ci guadagni. Scrivendo di meno sul disco significa fare meno accessi, e significa che il disco dura di piu`, che viene usato di meno (= piu` batteria sui portatili) e che va piu` veloce.

Tutti questi test sono stati abbondantemente verificati (personalmente e anche su vari siti) e anche la non perdita dei dati e` stata verificata.

Permetti un dubbio:
con HD con 32/64/128MB di cache,
anche se copi/scrivi tanti files da 1MB,
la testina del HD si muovera` soltanto a cache pieno,
nel frattempo pausa completa, inerzia tranne per le varie memorie.
Una volta piena la cache,
la logica del disco decidera` dove, _ed_ _in_ _quale_ _sequenza_,
scrivere i dati, impossibile che accetti ordini da SO e/o FS.

Prendi un programma in C che usa write(2) e che scrive 10 bytes ogni minuto,
quando sara veramente sul disco?

Anche se forzi con sync(2), la man page dice

BUGS
According to the standard specification (e.g., POSIX.1-2001), sync() schedules the writes, but may return before the actual writing is done. However, since version 1.3.20 Linux does
actually wait. (This still does not guarantee data integrity: modern disks have large caches.)

Quindi pura illusione con la HW moderna!

[shark1500]

la testina del HD si muovera` soltanto a cache pieno,

No, si puo` movere anche prima, dipende dalla logica del disco.

Una volta piena la cache,
la logica del disco decidera` dove, _ed_ _in_ _quale_ _sequenza_,
scrivere i dati, impossibile che accetti ordini da SO e/o FS.

Il disco cerca di scrivere tutto il piu` contiguo possibile, e se ha la cache piena di roba meglio, altrimenti rischia di frammentare molto.

Anche se forzi con sync(2), la man page dice

echo 3 > /proc/sys/vm/drop_cache

Secondo me stiamo andando altamente fuori tema. Se e` cosi` qualche staff ce lo faccia notare e (se Mario vuole) possiamo continuare in privato

[Mario Vanoni]

la testina del HD si muovera` soltanto a cache pieno,

No, si puo` movere anche prima, dipende dalla logica del disco.

Una volta piena la cache,
la logica del disco decidera` dove, _ed_ _in_ _quale_ _sequenza_,
scrivere i dati, impossibile che accetti ordini da SO e/o FS.

Il disco cerca di scrivere tutto il piu` contiguo possibile, e se ha la cache piena di roba meglio, altrimenti rischia di frammentare molto.

Anche se forzi con sync(2), la man page dice

echo 3 > /proc/sys/vm/drop_cache

Secondo me stiamo andando altamente fuori tema. Se e` cosi` qualche staff ce lo faccia notare e (se Mario vuole) possiamo continuare in privato

Chiudo qui`, con una ultima osservazione:
Il disco cerca di scrivere tutto il piu` contiguo possibile a lui,
non nella logica Linux/ext4 ecc. ecc.,
ma su settori contigui (|||..., le sue partizioni meccaniche, dischi singoli),
non su settori con abbastanza spazio per contenere il tutto in modo contiguo!
Come gia` detto, qui e` la grande illusione.

Sfido ogni SW ad indovinare che per un file di 700MB da scrivere su HD,
sul quarto disco del disco duro ci sia spazio contiguo a disposizione.