La traînée de poudre

---

Summary

    1. tools
    2. identifying devices
    3. handling tape cartridges in a library
    4. handling tape in a drive
        Drive information
        Density code
        Reading from the cartridge's RFID tag
        mt commands
    5. Identifying an unknown tape
    6. Basic use of gnu tar
    7. Using LTFS
    Appendix: other useful commands

1. tools

Tools used in this article are: mt (from mt-st package), mtx, tar and ltfs. We’ll optionnally need lsscsi, dd and sg3-utils.

mt is used to control the tape drive (tape movements, ejection, and drive settings). mtx is used to control tape libraries (moving cartridges from slots to drives, etc). We’ll use mostly tar to read and write, and dd to identify unknown tapes

During the initial configuration, we’ll use lsscsi to identify tape devices.

2.identifying devices

Let’s identify our devices using lsscsi.

~# lsscsi
[6:0:0:0]    disk    AMCC     9650SE-16M DISK  3.08  /dev/sda
[7:0:0:0]    tape    HP       Ultrium 5-SCSI   Z21U  /dev/st0
[7:0:0:1]    mediumx TANDBERG StorageLoader    0346  /dev/sch0

Our tape drives appears as /dev/st0. Unfortunately, by default the device listed for the tape library is useless, we’ll have to resort to lsscsi- g to get the corresponding generic SCSI device:

~# lsscsi -g
[6:0:0:0]    disk    AMCC     9650SE-16M DISK  3.08  /dev/sda  /dev/sg0
[7:0:0:0]    tape    HP       Ultrium 5-SCSI   Z21U  /dev/st0  /dev/sg1
[7:0:0:1]    mediumx TANDBERG StorageLoader    0346  /dev/sch0  /dev/sg2

mt can use either /dev/stXX or /dev/nstXX devices. the difference is as follows: /dev/stXX rewind the tape before any operation. /dev/nstXX doesn’t move the tape. Therefore we’ll generally use /dev/nstXX. tar (or in some cases dd) also uses the tape device /dev/nstXX (or /dev/stXX). mtx on the other hand, works with the generic SCSI device /dev/sgXX. Know the difference.

3. handling tape cartridges in a library

First, let’s check what’s in our tape library:

~# mtx -f /dev/sg2 status
  Storage Changer /dev/sg2:1 Drives, 8 Slots ( 0 Import/Export )
Data Transfer Element 0:Empty
      Storage Element 1:Full :VolumeTag=AAA013L4                        
      Storage Element 2:Empty
      Storage Element 3:Empty
      Storage Element 4:Empty
      Storage Element 5:Empty
      Storage Element 6:Empty
      Storage Element 7:Empty
      Storage Element 8:Empty

The “Data Transfer Element” lines represent tape drives (only one present in this example). “Storage Element” lines represent the cartridge slots. Depending upon your hardware, you may also have “Input Output Element” lines, which are “mail slots” that allow moving tapes in and out the library without interrupting normal operations.

If the cartridges carry barcode labels and your library supports these, mtx also display that label value, as shown in the example above.

We can see that our “Data Transfer Element 0” is empty; let’s load it with a tape:

~# mtx -f /dev/sg2 load 1 0
~#

As a proper Unix program, mtx is quiet if nothing’s wrong. Let’s check the status again; we’ll see that mtx remembers from which slot comes the tape now in our drive:

~# mtx -f /dev/sg2 status
  Storage Changer /dev/sg2:1 Drives, 8 Slots ( 0 Import/Export )
Data Transfer Element 0:Full (Storage Element 1 Loaded):VolumeTag=AAA013L4
      Storage Element 1:Empty
      Storage Element 2:Empty
      Storage Element 3:Empty
      Storage Element 4:Empty
      Storage Element 5:Empty
      Storage Element 6:Empty
      Storage Element 7:Empty
      Storage Element 8:Empty

Using the command mtx -f /dev/sg2 unload without source nor destination will unload the tape from the first drive into its original location. Of course you could alternatively unload the tape to any empty slot instead.

~# mtx -f /dev/sg2 unload 4 0 
Unloading Data Transfer Element into Storage Element 4...done

Notice that mtx emit a message in that case. So it’s not that conforming to the Unix way after all :)

Nota Bene: with some libraries or drives (but generally not LTO drives), it may be necessary to first ask for the drive to eject the tape before asking for the library to move out the tape from the drive. So you may want to run mt offline with the appropriate options before any mtx unload command, just to be sure.

Last, mtx can also move tapes from slot to slot, which is particularly useful when using a IO slot (or mail slot):

~# mtx -f /dev/sg2 transfer 4 2

4. handling tape in a drive

mt can move the tape ( forward, rewinf, eject), erase, enable or disable compression, define the block size to use, etc.

First let’s check drive status:

 ~# mt -f /dev/nst0 status
drive type = Generic SCSI-2 tape
drive status = 1476395008
sense key error = 0
residue count = 0
file number = 0
block number = 0
Tape block size 0 bytes. Density code 0x58 (unknown).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

Drive informations

Drive status is read line by line :

statut	signification
drive type	attachment type (normally always SCSI)
drive status	some code I don’t know much about…
sense key error	communication error status
residue count	?
file number	record number (file) on which the tape is currently positioned
block number	block number on which the tape is currently positioned
Tape block size X bytes	current hardware block size, it’s generally advised to let it at zero (soft block size)
Density code	Tape type and density, see table below
Soft error count	number of errors in the current session

Status Codes

The two last lines of output display “status bits”, listed below:

Status Bit	Description
BOT	Beginning Of tape (Beginning of First File)
EOT	End Of Tape (either physical End of Tape, or End of Data area)
EOF	At the End Of some File
WR_PROT	Write Protected. Either the drive or tape is in write-protected mode; or the current drive only supports this tape type in read-only mode.
ONLINE	Drive loaded and ready to work.
DR_OPEN	Drive Open. The drive is empty, or the tape has been ejected and hangs at the door (in that case, you can use *mt load* to load the tape).
IM_REP_EN	Immediate Response Mode. the drive buffers data and acknowledge read and write operations before data has hit the tape.
SM	Tape is on a Marker (Set Mark). May work only on DDS drives(?)
EOD	End Of Data. The tape is at the end of recorded area. Depending upon drives, may be the same thing as EOT

density codes

Here is a list of density codes compiled along the years from various sources (Internet, our own drives, etc):

code	description
0x00	default
0x01	NRZI (800 bpi)
0x02	PE (1600 bpi)
0x03	GCR (6250 bpi)
0x04	QIC-11
0x05	QIC-45/60 (GCR, 8000 bpi)
0x06	PE (3200 bpi)
0x07	IMFM (6400 bpi)
0x08	GCR (8000 bpi)
0x09	GCR (37871 bpi)
0x0a	MFM (6667 bpi)
0x0b	PE (1600 bpi)
0x0c	GCR (12960 bpi)
0x0d	GCR (25380 bpi)
0x0f	QIC-120 (GCR 10000 bpi)
0x10	QIC-150/250 (GCR 10000 bpi)
0x11	QIC-320/525 (GCR 16000 bpi)
0x12	QIC-1350 (RLL 51667 bpi)
0x13	DDS (61000 bpi)
0x14	EXB-8200 (RLL 43245 bpi)
0x15	EXB-8500 or QIC-1000
0x16	MFM 10000 bpi
0x17	MFM 42500 bpi
0x18	TZ86
0x19	DLT 10GB
0x1a	DLT 20GB
0x1b	DLT 35GB
0x1c	QIC-385M
0x1d	QIC-410M
0x1e	QIC-1000C
0x1f	QIC-2100C
0x20	QIC-6GB
0x21	QIC-20GB
0x22	QIC-2GB
0x23	QIC-875
0x24	DDS-2
0x25	DDS-3
0x26	DDS-4 or QIC-4GB
0x27	Exabyte Mammoth
0x28	Exabyte Mammoth-2
0x29	QIC-3080MC
0x30	AIT-1 or MLR3
0x31	AIT-2
0x32	AIT-3 / SLR7
0x33	SLR6
0x34	SLR100
0x40	DLT1 40 GB, or Ultrium
0x41	DLT 40GB, or Ultrium2
0x42	LTO-2
0x44	LTO-3
0x45	QIC-3095-MC (TR-4)
0x46	LTO-4
0x47	TR-5 / DDS-5
0x48	Quantum SDLT220
0x49	Quantum SDLT320
0x51	IBM 3592 J1A
0x52	IBM 3592 E05
0x58	LTO-5
0x5a	LTO-6
0x5c	LTO-7
0x5d	LTO-M8
0x5e	LTO-8
0x80	DLT 15GB uncomp. or Ecrix / VXA-1
0x81	DLT 15GB compressed / VXA-2
0x82	DLT 20GB uncompressed / VXA-3 / VXA-320
0x83	DLT 20GB compressed
0x84	DLT 35GB uncompressed
0x85	DLT 35GB compressed
0x86	DLT1 40 GB uncompressed
0x87	DLT1 40 GB compressed
0x88	DLT 40GB uncompressed
0x89	DLT 40GB compressed
0x8c	EXB-8505 compressed
0x90	SDLT110 uncompr/EXB-8205 compr
0x91	SDLT110 compressed
0x92	SDLT160 uncompressed
0x93	SDLT160 compressed

Reading from the cartridge’s RFID tag

LTO cartridges carry an RFID chip that stores all sorts of information. To read this chip using the tape drive, you’ll need the sg_logs command from sg3-utils package. The first line of output is drive information, and everything else is about the tape:

 ~# sg_logs -p 0x17 /dev/sg2 
    TANDBERG  LTO-5 HH          Z629
Volume statistics page (ssc-4), subpage=0
  Page valid: 1
  Thread count: 40
  Total data sets written: 1429926
  Total write retries: 2
  Total unrecovered write errors: 0
  Total suspended writes: 43
  Total fatal suspended writes: 0
  Total data sets read: 4186
  Total read retries: 1
  Total unrecovered read errors: 0
  Last mount unrecovered write errors: 0
  Last mount unrecovered read errors: 0
  Last mount megabytes written: 0
  Last mount megabytes read: 0
  Lifetime megabytes written: 3534834
  Lifetime megabytes read: 10347
  Last load write compression ratio: 0
  Last load read compression ratio: 8391
  Medium mount time: 73309203
  Medium ready time: 73309203
  Total native capacity [MB]: 1529930
  Total used native capacity [MB]: 7250
  Volume serial number: MG1NVN224A
  Tape lot identifier: G5ABP25R
  Volume barcode: ST1008                          
  Volume manufacturer: FUJIFILM
  Volume license code: U107
  Volume personality: Ultrium-5
  Write protect: 0
  WORM: 0
  Maximum recommended tape path temperature exceeded: 0
  Beginning of medium passes: 267
  Middle of medium passes: 203
  Logical position of first encrypted logical object:
    partition number: 0, partition record data counter: 0xffffffffffff
  Logical position of first unencrypted logical object after first
  encrypted logical object:
    partition number: 0, partition record data counter: 0xffffffffffff
  Native capacity partition(s) [MB]:
    partition number: 0, partition record data counter: 1529930
  Used native capacity partition(s) [MB]:
    partition number: 0, partition record data counter: 7250
  Vendor specific parameter code (0xf000), payload in hex
 00     00 01                                               ..

mt Command

Most common options of mt are listed below:

commande	description
Information
status	displays tape and drive information
Drive parameters
setdensity X	Set Density Code. Used to enable or disable hardware compression.
setblk X	Define hardware block size. Normally always at 0 (“dynamic” or “soft blocks”)
drvbuffer X	enable (1) or disable (0)drive buffering. Other values may apply to some types of drives.
stoptions X	Set options for the *st* tape driver. Usual values are: 1 to enable write buffering, 2 to enable asynchronous writes, and 8 for debugging.
Movement
rewind	rewind tape.
retension	rewind tape, then fast forward to the end of tape, then rewind again.
offline	rewind then eject tape.
fsf X	Forward X files. tape is positioned on the first block of the next file.
fsfm X	Forward X files. tape is positioned on the last block of the previous file. Same effect as fsf X + bsf 1
bsf X	Backward X files. Tape is positioned on the last block of the previous file
bsfm X	Backward X files. Tape is positioned on the first block of the next file, same effect as bsf X + fsf 1
asf X	Position to the Xth file on tape: rewind then forward X files ( like fsf ).
eod,seod	Forward to the end of data. Obsolete and equivalent : eom.
fsr X	Forward X records.
bsr X	Backward X records
fss X	Forward X markers (setmarks).
bss X	Backward X markers
seek X	Move tape to block X.
tell	Display the current block
Writing to tape
eof, weof X	Write X “End of file” markers at current position.
wset X	Write X “Set mark” markers at current position.
erase	Erase the tape from the beginning. Caution: the drive will remain in use until the whole tape has been zeroed out, typically for several hours

Each writing operaion on tape with a tool like tar, cpio, etc creates a “file”, identified with an “EOF” (End of file) marker. After writing 3 files on tape, you may move from one file to the other using mt fsf/bsf.

5. Identifying an unknown tape

To identify an unknown tape, we’ll first try to determine the block size used to write it. We’ll set up our drive to zero block size (dynamic block size):

mt -f /dev/nst0 setblk 0

Then we’ll read a full block using dd. We’ll suppose that the bloc probably won’t be bigger than 512KiB and write the output into a file /tmp/TESTTAPE :

~# dd if=/dev/nst0 bs=512k of=/tmp/TESTTAPE count=1
1+0 records in
1+0 records out
32768 bytes (33 kB, 32 KiB) copied, 3,76924 s, 8,7 kB/s

In our example we see that our block is 32KiB. Now what sort of file is this? Let’s use the file command :

 ~# file /tmp/TESTTAPE 
/tmp/TESTTAPE2: ASCII cpio archive (SVR4 with no CRC)

If file can’t name our data, we can try strings :

:~# file /tmp/TESTTAPE
/tmp/TESTTAPE: data
~# strings /tmp/TESTTAPE 
-**#( NetVault Header )#**-
rcserveur 22 sept. 04:29-1
rcpartages

6. Basic use of gnu tar

We’ll list the most common parameters for tar :

-c  write to the target device
-t  list content of target device
-x  restore from target device
-f  target device ( for example */dev/nst0* )
-v  verbose mode (list current operation)
-b  block size to use in units of 512 bytes. Common values: 64, 128; 256 (default value is a paltry 20)

Writing to tape:

tar -c -v -f /dev/nst0 -b 128 /un/dossier/à/archiver/

Write to /dev/nst0 in 64 KiB ( 128 * 512 bytes) blocks. Overwrite whatever was at this position and to the end of tape.

7. Using LTFS

LTFS (Long Term File System) is a multi-platform industry standard that provides wide compatibility of LTO-5 (and higher) cartridges between operating systems and software solutions. An LTFS-formatted LTO tape appears as a file system similar to a USB disk drive. Free utilities are available from tape drive providers (IBM, Quantum, HP, etc) for Windows, MacOS and Linux.

As LTFS for Debian is generally unavailable, here is a version I’ve built here (Debian 10 or 11). Dependancies aren’t defined, so you may need to manually install fuse tools.

The Linux LTFS tools are quite simple. The main one is the ltfs command that mounts (using fuse) the tape for reading and writing. Caution : just like mtx and other tools, ltfs uses the generic SCSI device /dev/sgXX instead of the tape device /dev/stXX.

Using ltfs is very easy. The program is very verbose, so I’ll omit some of its output in the example below:

 ~# ltfs -o devname=/dev/sg2 /mnt/ltfs

6127 LTFS14000I LTFS starting, LTFS version 2.5.0.0 (Prelim), log level 2.                  
6127 LTFS14058I LTFS Format Specification version 2.4.0.                        
6127 LTFS14104I Launched by "ltfs -o devname=/dev/sg2 /mnt/ltfs".                     
6127 LTFS14105I This binary is built for Linux (x86_64).
6127 LTFS14106I GCC version is 8.3.0.
6127 LTFS17087I Kernel version: Linux version 4.19.0-16-amd64 
    (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) 
    #1 SMP Debian 4.19.181-1 (2021-03-19) i386.
6127 LTFS17089I Distribution: PRETTY_NAME="Debian GNU/Linux 10 (buster)".

[...]

6127 LTFS14111I Initial setup completed successfully.
6127 LTFS14112I Invoke 'mount' command to check the result of final setup.
6127 LTFS14113I Specified mount point is listed if succeeded.

Following the advice from the last line of output, you should use mount to check that the tape is mounted:

 ~# mount -t ltfs
 ltfs:/dev/sg2 on /mnt/ltfs type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

You can then read and write to the tape like on any filesystem, but with very high latency. Tape positioning can take several minutes. Simply unmount the tape with umount when done (it can be pretty long, too).

Appendix: other useful commands

Sometimes your tape library may be locked, for instance because a software using it crashed, or it was unplugged during operations. You can unlock it with the following command (replace /dev/sg2 with the appropriate device):

sg_prevent -av /dev/sg2

Une nouvelle version de la documentation avancée pour StorIQ NAS 8.0 est disponible ici et depuis la section Documentation du site.

Vous y trouverez plein de détails rarement disponibles en français sur la configuration de “clusters” avec DRBD, Corosync, et Pacemaker; également tout sur la configuration de cibles iSCSI LIO avec target-cli, ainsi que la configuration de caches SSD avec LVM.

---

Sommaire

    1. outils
    2.identification des périphériques
    3. manipulation des cartouches dans la bibliothèque
    4. manipulation de la bande dans le lecteur
        Informations sur le lecteur
        Codes de densité
        lecture de la puce RFID de la LTO
        commandes mt
    5. identification d'un support inconnu
    6. utilisation basique de tar
    7. utilisation de LTFS
    Appendice: autres commandes utiles

1. outils

Les outils utilisés sont : mt (du paquet mt-st), mtx, tar et ltfs. Accessoirement nous aurons besoin de lsscsi et dd ainsi que des sg3-utils.

mt permet de piloter les lecteurs de bande (transport, éjection, paramétrage). mtx permet de piloter les bibliothèques de bande (mouvements, chargement, etc). Nous utiliserons principalement tar pour lire et écrire, et dd pour identifier une bande inconnue.

Pour la première configuration, nous aurnos aussi besoin de lsscsi afin d’identifier les périphériques à utiliser.

2.identification des périphériques

Il nous faut identifier les périphériques, à l’aide de lsscsi:

~# lsscsi
[6:0:0:0]    disk    AMCC     9650SE-16M DISK  3.08  /dev/sda
[7:0:0:0]    tape    HP       Ultrium 5-SCSI   Z21U  /dev/st0
[7:0:0:1]    mediumx TANDBERG StorageLoader    0346  /dev/sch0

Le lecteur de bande apparait ici comme /dev/st0. Le périphérique listé pour la bibliothèque n’est pas le bon, il faut utiliser lscsi -g pour afficher les périphériques génériques SCSI correspondants :

~# lsscsi -g
[6:0:0:0]    disk    AMCC     9650SE-16M DISK  3.08  /dev/sda  /dev/sg0
[7:0:0:0]    tape    HP       Ultrium 5-SCSI   Z21U  /dev/st0  /dev/sg1
[7:0:0:1]    mediumx TANDBERG StorageLoader    0346  /dev/sch0  /dev/sg2

mt utilise le périphérique /dev/stXX ou /dev/nstXX. La différence : /dev/stXX rembobine automatiquement la bande avant toute opération. /dev/nstXX ne rembobine pas. C’est donc normalement /dev/nstXX qu’on utilise. tar (ou le cas échéant dd) travaille également avec le périphérique bande /dev/nstXX (ou /dev/stXX). mtx par contre, utilise le périphérique générique SCSI /dev/sgXX. Apprenez à connaitre la différence.

3. manipulation des cartouches dans la bibliothèque

Tout d’abord, passons en revue le contenu de la bibliothèque :

~# mtx -f /dev/sg2 status
  Storage Changer /dev/sg2:1 Drives, 8 Slots ( 0 Import/Export )
Data Transfer Element 0:Empty
      Storage Element 1:Full :VolumeTag=AAA013L4                        
      Storage Element 2:Empty
      Storage Element 3:Empty
      Storage Element 4:Empty
      Storage Element 5:Empty
      Storage Element 6:Empty
      Storage Element 7:Empty
      Storage Element 8:Empty

Les lignes “Data Transfer Element” correspondent aux lecteurs, un seul ici. Les lignes “Storage Element” correspondent aux emplacements de stockage; enfin le cas échéant, il peut y avoir des lignes “Input Output Element” qui sont des ports d’entrée/sortie permettant d’ajouter ou retirer des cartouches de la bibliothèque.

Si les cartouches sont dotées de codes à barres et que la bibliothèque les supportent, mtx affiche également ce code-barre, comme on peut le voir dans l’exemple ci-dessus.

La ligne “Data Transfer Element 0” donne l’état du premier lecteur (en l’espèce, vide). Chargeons-y une cassette :

~# mtx -f /dev/sg2 load 1 0
~#

Notons que si tout se passe bien, mtx reste muet, conforme en cela à la tradition unixienne. Si on regarde à nouveau le “status” on verra que mtx connait la provenance de la bande qui est maintenant dans le lecteur :

~# mtx -f /dev/sg2 status
  Storage Changer /dev/sg2:1 Drives, 8 Slots ( 0 Import/Export )
Data Transfer Element 0:Full (Storage Element 1 Loaded):VolumeTag=AAA013L4
      Storage Element 1:Empty
      Storage Element 2:Empty
      Storage Element 3:Empty
      Storage Element 4:Empty
      Storage Element 5:Empty
      Storage Element 6:Empty
      Storage Element 7:Empty
      Storage Element 8:Empty

Si on utilise la commande mtx -f /dev/sg2 unload sans indiquer de source ni de destination, la cassette du premier lecteur sera replacée dans son emplacement d’origine. On peut naturellement l’éjecter vers un emplacement libre au choix:

~# mtx -f /dev/sg2 unload 4 0 
Unloading Data Transfer Element into Storage Element 4...done

Remarquons au passage que mtx n’est pas très cohérent, puisqu’il émet un message dans ce cas.

Nota Bene: sur certains type de lecteurs, il peut être nécessaire de commander l’éjection de la bande par le lecteur avant de commander son déchargement par la bibliothèque. Par précaution, on précèdera donc toujours un mtx unload par le mt offline approprié (voir plus loin).

Il est aussi possible de transférer des cartouches entre différents emplacements, ce qui est surtout utile lorsqu’on est équipé d’un port d’entrée/sortie :

~# mtx -f /dev/sg2 transfer 4 2

4. manipulation de la bande dans le lecteur

mt permet de transporter la bande ( avancer, reculer, éjecter), effacer, activer/désactiver la compression, définir la taille de bloc utilisée, etc.

Commençons par visualiser le status du lecteur :

 ~# mt -f /dev/nst0 status
drive type = Generic SCSI-2 tape
drive status = 1476395008
sense key error = 0
residue count = 0
file number = 0
block number = 0
Tape block size 0 bytes. Density code 0x58 (unknown).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

Informations sur le lecteur

Le statut du lecteur se lit ligne par ligne :

statut	signification
drive type	type d’attachement (normalement, toujours SCSI)
drive status	un code incompréhensible
sense key error	status d’erreur de communication
residue count	?
file number	numéro d’enregistrement (fichier) dans lequel la bande est positionnée
block number	position en blocs où la bande est actuellement positionnée
Tape block size X bytes	taille de bloc matériel utilisé, sauf cas particulier doit toujours être à zéro
Density code	densité de la bande, voir tableau ci-dessous
Soft error count	nombre d’erreurs rencontrées

Codes de statut

Les deux dernières lignes concernent les “bits de statut”, qui sont définis selon le tableau suivant :

Status Bit	Description
BOT	au début de la bande (début du premier fichier)
EOT	à la fin de la bande (fin de la partie enregistrée)
EOF	positionné à la fin d’un fichier
WR_PROT	protégé en écriture. Soit le lecteur, soit la bande est en mode protégé; ou bien le lecteur ne supporte ce type de bande qu’en lecture seule.
ONLINE	Le lecteur est chargé avec une bande et prêt à fonctionner.
DR_OPEN	Porte ouverte. Normalement, signifie que le lecteur est vide.
IM_REP_EN	mode de retour immédiat. Le lecteur tamponne les données et rend la main avant que les données soient physiquement enregistrées sur le média.
SM	La bande est positionné sur un marqueur ( set mark). Spécifique aux lecteurs DDS(?)
EOD	La bande est positionnée à la fin de la partie enregistrée. Selon les lecteurs, équivalent ou pas à EOT

Codes de densité

Voici les codes compilés par moi depuis plusieurs sources (Internet, nos lecteurs…)

code	description
0x00	default
0x01	NRZI (800 bpi)
0x02	PE (1600 bpi)
0x03	GCR (6250 bpi)
0x04	QIC-11
0x05	QIC-45/60 (GCR, 8000 bpi)
0x06	PE (3200 bpi)
0x07	IMFM (6400 bpi)
0x08	GCR (8000 bpi)
0x09	GCR (37871 bpi)
0x0a	MFM (6667 bpi)
0x0b	PE (1600 bpi)
0x0c	GCR (12960 bpi)
0x0d	GCR (25380 bpi)
0x0f	QIC-120 (GCR 10000 bpi)
0x10	QIC-150/250 (GCR 10000 bpi)
0x11	QIC-320/525 (GCR 16000 bpi)
0x12	QIC-1350 (RLL 51667 bpi)
0x13	DDS (61000 bpi)
0x14	EXB-8200 (RLL 43245 bpi)
0x15	EXB-8500 or QIC-1000
0x16	MFM 10000 bpi
0x17	MFM 42500 bpi
0x18	TZ86
0x19	DLT 10GB
0x1a	DLT 20GB
0x1b	DLT 35GB
0x1c	QIC-385M
0x1d	QIC-410M
0x1e	QIC-1000C
0x1f	QIC-2100C
0x20	QIC-6GB
0x21	QIC-20GB
0x22	QIC-2GB
0x23	QIC-875
0x24	DDS-2
0x25	DDS-3
0x26	DDS-4 or QIC-4GB
0x27	Exabyte Mammoth
0x28	Exabyte Mammoth-2
0x29	QIC-3080MC
0x30	AIT-1 or MLR3
0x31	AIT-2
0x32	AIT-3 / SLR7
0x33	SLR6
0x34	SLR100
0x40	DLT1 40 GB, or Ultrium
0x41	DLT 40GB, or Ultrium2
0x42	LTO-2
0x44	LTO-3
0x45	QIC-3095-MC (TR-4)
0x46	LTO-4
0x47	TR-5 / DDS-5
0x48	Quantum SDLT220
0x49	Quantum SDLT320
0x51	IBM 3592 J1A
0x52	IBM 3592 E05
0x58	LTO-5
0x5a	LTO-6
0x5c	LTO-7
0x5d	LTO-M8
0x5e	LTO-8
0x80	DLT 15GB uncomp. or Ecrix / VXA-1
0x81	DLT 15GB compressed / VXA-2
0x82	DLT 20GB uncompressed / VXA-3 / VXA-320
0x83	DLT 20GB compressed
0x84	DLT 35GB uncompressed
0x85	DLT 35GB compressed
0x86	DLT1 40 GB uncompressed
0x87	DLT1 40 GB compressed
0x88	DLT 40GB uncompressed
0x89	DLT 40GB compressed
0x8c	EXB-8505 compressed
0x90	SDLT110 uncompr/EXB-8205 compr
0x91	SDLT110 compressed
0x92	SDLT160 uncompressed
0x93	SDLT160 compressed

lecture de la puce RFID de la LTO

Les cartouches de type LTO ont une puce RFID. En lisant cette puce on peut récupérer une foule d’informations. Pour cela il faut utiliser la commande sg_logs du paquet sg3-utils. La première ligne de sortie donne les informations du lecteur. Le reste concerne la cartouche.

 ~# sg_logs -p 0x17 /dev/sg2 
    TANDBERG  LTO-5 HH          Z629
Volume statistics page (ssc-4), subpage=0
  Page valid: 1
  Thread count: 40
  Total data sets written: 1429926
  Total write retries: 2
  Total unrecovered write errors: 0
  Total suspended writes: 43
  Total fatal suspended writes: 0
  Total data sets read: 4186
  Total read retries: 1
  Total unrecovered read errors: 0
  Last mount unrecovered write errors: 0
  Last mount unrecovered read errors: 0
  Last mount megabytes written: 0
  Last mount megabytes read: 0
  Lifetime megabytes written: 3534834
  Lifetime megabytes read: 10347
  Last load write compression ratio: 0
  Last load read compression ratio: 8391
  Medium mount time: 73309203
  Medium ready time: 73309203
  Total native capacity [MB]: 1529930
  Total used native capacity [MB]: 7250
  Volume serial number: MG1NVN224A
  Tape lot identifier: G5ABP25R
  Volume barcode: ST1008                          
  Volume manufacturer: FUJIFILM
  Volume license code: U107
  Volume personality: Ultrium-5
  Write protect: 0
  WORM: 0
  Maximum recommended tape path temperature exceeded: 0
  Beginning of medium passes: 267
  Middle of medium passes: 203
  Logical position of first encrypted logical object:
    partition number: 0, partition record data counter: 0xffffffffffff
  Logical position of first unencrypted logical object after first
  encrypted logical object:
    partition number: 0, partition record data counter: 0xffffffffffff
  Native capacity partition(s) [MB]:
    partition number: 0, partition record data counter: 1529930
  Used native capacity partition(s) [MB]:
    partition number: 0, partition record data counter: 7250
  Vendor specific parameter code (0xf000), payload in hex
 00     00 01                                               ..

Commandes mt

Les options de mt les plus couramment utilisées sont listées ci-dessous :

commande	description
Information
status	affiche les informations du lecteur et de la bande (voir ci-dessus)
Paramètres du lecteur
setdensity X	définit la densité du lecteur (voir ci-dessus). Utilisé pour activer/désactiver la compression.
setblk X	définit la taille de bloc matériel. Normalement toujours à zéro (“blocs dynamiques”)
drvbuffer X	active (1) ou désactive (0) le tampon du lecteur. D’autres valeurs peuvent être valides selon les lecteurs.
stoptions X	utilisé pour activer les options du pilote de bande. Les valeurs courantes sont : 1 pour activer le tampon en écriture, 2 pour activer les écritues asynchrones, et 8 pour le déboguage.
transport
rewind	rembobine la bande.
retension	rembobine la bande, bobine la bande jusqu’au bout, puis rembobine à nouveau la bande.
offline	rembobine puis éjecte la bande.
fsf X	Avancer de X fichiers. La bande est positionnée sur le premier bloc du fichier suivant.
fsfm X	Avancer de X fichiers. La bande est positionnée sur le dernier bloc du fichier précédent. Équivalent à fsf X + bsf 1
bsf X	Reculer de X fichiers. La bande est positionnée sur le dernier bloc du fichier précédent.
bsfm X	Reculer de X fichiers. La bande est positionnée sur le premier bloc du fichier suivant, équivalent à bsf X + fsf 1
asf X	positionnement absolu: rembobine puis avance de X fichiers (comme fsf ).
eod,seod	avance jusqu’à la fin de la zone de données. Équivalent obsolète : eom.
fsr X	avance de X enregistrements. (différence avec fsf? )
bsr X	recule de X enregistrements.
fss X	avance de X marqueurs (setmarks).
bss X	recule de X marqueurs.
seek X	positionne la bande au bloc X.
tell	indique le bloc courant sur la bande
écriture sur bande
eof, weof X	écrit X marqueurs “fin de fichier” à la position courante.
wset X	écrit X marqueurs (setmarks) à la position courante.
erase	Efface la bande. Attention, le lecteur rend la main et reste indisponible jusqu’à la fin de l’opération, qui est très longue (1 heure ou plus)

Chaque opération d’écriture sur la bande à l’aide d’un outil comme tar, cpio, etc. crée un “fichier”, identifié par son marqueur “EOF” (fin de fichier). Si on écrit successivement 3 fichiers tar sur la bande, on peut se positionner avec mt fsf/bsf sur l’archive à lire.

5. identification d’un support inconnu

Pour identifier un support inconnu, on cherchera d’abord à connaître la taille de blocs. On règle donc celle du lecteur à zéro (blocs dynamiques):

mt -f /dev/nst0 setblk 0

Ensuite on extrait un bloc entier en utilisant dd. On suppose que le bloc ne fait probablement pas plus que 512Ko et on écrit le résultat dans le fichier /tmp/TESTTAPE :

~# dd if=/dev/nst0 bs=512k of=/tmp/TESTTAPE count=1
0+1 enregistrements lus
0+1 enregistrements écrits
32768 octets (33 kB) copiés, 3,76924 seconde, 8,7 kB/s

On voit que le bloc fait 32 Ko… Maintenant il s’agit d’identifier ce fichier… Avec file par exemple :

 ~# file /tmp/TESTTAPE 
/tmp/TESTTAPE2: ASCII cpio archive (SVR4 with no CRC)

En cas de fichier récalcitrant, on peut toujours utiliser strings :

:~# file /tmp/TESTTAPE
/tmp/TESTTAPE: data
~# strings /tmp/TESTTAPE 
-**#( NetVault Header )#**-
rcserveur 22 sept. 04:29-1
rcpartages

6. utilisation basique de tar

Les paramètres de base de tar que nous utiliserons sont :

-c  écrire sur la cible
-t  liste le contenu de la cible
-x  restaurer depuis la cible
-f  fichier cible ( par exemple /dev/nst0 )
-v  verbeux, détaille les opérations en cours
-b  taille de bloc à utiliser (GROS!)

Exemple d’écriture :

tar -c -v -f /dev/nst0 -b 128 /un/dossier/à/archiver/

Écrit sur /dev/nst0 avec des blocs de 64 Ko, tout le dossier et son contenu.

7. utilisation de ltfs

LTFS (long term file system) est une solution multiplateformes qui permet d’utiliser facilement des bandes LTO (LTO-5 minimum) de manière simple en simulant un disque amovible. La bande LTFS se présente donc comme un système de fichiers semblable à un disque USB. Des utilitaires gratuits sont disponibles sur les sites de constructeurs (IBM, HP, Quantum, etc) pour Windows, MacOS et Linux (RedHat et Suse uniquement).

Une version compilée pour Debian 10 est disponible ici. Attention, c’est un paquet de test dont les dépendances ne sont pas définies, vous devrez les installer manuellement.

Les outils LTFS pour linux sont assez simples. Le premier est la commande ltfs qui permet grâce à fuse, de monter la bande afin de la lire et d’y écrire. Attention, comme mtx, ltfs utilise le périphérique SCSI /dev/sgXX et non le lecteur de bandes /dev/stXX.

L’utilisation de ltfs est très simple. Le programme étant très bavard, j’ai omis une partie des messages:

 ~# ltfs -o devname=/dev/sg2 /mnt/ltfs

6127 LTFS14000I LTFS starting, LTFS version 2.5.0.0 (Prelim), log level 2.                  
6127 LTFS14058I LTFS Format Specification version 2.4.0.                        
6127 LTFS14104I Launched by "ltfs -o devname=/dev/sg2 /mnt/ltfs".                     
6127 LTFS14105I This binary is built for Linux (x86_64).
6127 LTFS14106I GCC version is 8.3.0.
6127 LTFS17087I Kernel version: Linux version 4.19.0-16-amd64 
    (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) 
    #1 SMP Debian 4.19.181-1 (2021-03-19) i386.
6127 LTFS17089I Distribution: PRETTY_NAME="Debian GNU/Linux 10 (buster)".

[...]

6127 LTFS14111I Initial setup completed successfully.
6127 LTFS14112I Invoke 'mount' command to check the result of final setup.
6127 LTFS14113I Specified mount point is listed if succeeded.

On peut, comme le recommande la dernière ligne, utiliser mount pour vérifier qu’on retrouve bien notre bande LTFS:

 ~# mount -t ltfs
 ltfs:/dev/sg2 on /mnt/ltfs type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

On pourra alors lire et écrire sur la bande comme sur un disque dur ordinaire, mais avec des latences beaucoup plus importantes bien entendu (positionner la bande peut prendre plusieurs minutes), puis la démonter simplement avec umount.

Appendice: autres commandes utiles

En cas de verrouillage intempestif de la bibliothèque de bandes, on peut la déverrouiller en envoyant une commande SCSI :

sg_prevent -av /dev/sg2

---

article paru dans le numéro 366 de “la revue des ingénieurs ESME SUDRIA”

L’archivage une approche holistique

L’archivage est un ensemble de pratiques transversales visant à préserver la connaissance. Il se distingue nettement de la sauvegarde en ce qu’il ne vise pas à la continuité de la production immédiate, mais bien à la conservation à long terme des informations, des savoirs, des pratiques.

Le passage de beaucoup des processus archivistiques dans le domaine numérique impacte significativement les pratiques, les méthodes, les ressorts économiques et les métiers de l’archivage.

Motivations de l’archivage

on distingue essentiellement deux grandes catégories dans l’archivage en général et l’archivage électronique en particulier, selon leur motivation principale:

• l’archivage à valeur probante qui vise à garantir l’intégrité et l’authenticité, généralement sur une durée définie de façon réglementaire et rarement supérieure à 10 ans (factures, contrats, etc). C’est ce que recouvrent les solutions dites “coffres-forts électroniques”. C’est l’approche utilisée dans la banque, la finance, l’administration. Dans cette approche, un accent particulier est mis sur les normes, les certifications, les éléments à valeur de preuve (horodatage certifié, signature électronique, validation par tiers de confiance, infrastructures de clefs publiques…).

• l’archivage patrimonial : de très longue durée, voire définitif, il vise à conserver le maximum d’informations utiles à fins d’exploitation éventuelle ultérieure. Il y a de nombreuses approches en fonction des opérations ultérieures envisagées, selon qu’il s’agit de données industrielles ou d’ingénierie, de données scientifiques ou techniques, à valeur artistique, etc.

Dans un cadre industriel (voir encadré Airbus) les informations nécessaires et les cadres possibles de leur exploitation ultérieure sont évidemment bien différents d’un archivage de données scientifiques (par exemple les données collectées par de grands instruments physiques ou astronomiques), ou à visée historique plus large (dépôt légal, conservation à caractère artistique ou muséal, etc).

Évolution de l’archivage

Le métier de l’archiviste accompagne de plus en plus le processus métier. S’il n’est jamais trop tard pour archiver, il peut être intéressant d’intégrer la problématique d’archivage dès le début du processus de production d’information, afin de pouvoir archiver le maximum d’information sur les données (métadonnées), et ce au fur et à mesure même de la production si possible. Une fois l’archivage terminé, on continuera à enrichir les métadonnées lorsqu’une requête fait ressortir les données, ou fait ressortir de nouvelles relations entre données archivées à des périodes différentes. Ainsi les données peuvent prendre de la valeur par leur enrichissement ultérieur, leurs croisements, etc.

Historiquement, une stratégie d’archivage venait en fin de production et/ou d’exploitation de la donnée: lorsqu’un document, livre, film était publié en version définitive, par exemple. L’archivage était alors un “sort final du document” et c’est encore l’approche généralement utilisée dans le cadre de l’archivage légal et de l’archivage à valeur probante.

Cet archivage définitif se produit selon deux modes principaux : lors de la finalisation du produit (par exemple un livre chez un éditeur), un exemplaire est envoyé au dépôt légal qui tient lieu d’archive définitive.

La numérisation permet cependant une approche renouvelée, en ce qu’elle permet d’enrichir les archives d’informations nouvelles en fonction des utilisations et de nouvelles techniques: par exemple l’INA pourra faire des statistiques sur les médias les plus consultés, et donc d’une part modifier la stratégie de stockage des données (pour faciliter l’accès aux plus demandées), et enrichir ces mêmes données de nouvelles informations (comme “telle archive de 1982 est la vidéo la plus consultée par les internautes en octobre 2014”). Ou bien de nouvelles fonctionnalités comme la conversion automatique de la parole en texte, ou la reconnaissance de visages, permettront une indexation beaucoup plus fine des vidéos.

Ainsi, quoique les éléments d’origine de l’archive n’évoluent plus, elle est néanmoins susceptible de s’enrichir sans cesse de nouvelles métadonnées ouvrant la voie à de nouveaux usages.

Il y a également un important travail qui consiste à “migrer” un fond vers un nouveau format: les livres, films et cassettes vidéos sont alors numérisé pour une exploitation plus aisée (indexation, recherche facilitée, nouvelle publication aisée).

Sujet complexe, se pose aussi le problème de la migration des formats physiques et des formats de données: s’il est encore relativement aisé de lire une disquette 3,5 pouces, il devient délicat de récupérer une disquette 8 pouces, une bande DECTape… Les supports numériques ont souvent été conçus sans tenir compte de leur capacité à perdurer et à rester exploitables. La situation est encore plus complexe pour les formats issus de différents logiciels: certains types de données sont enregistrées dans des formats propriétaires, peut-être issues de logiciels anciens peu répandus, dont les éditeurs ont pu disparaître, ainsi que le matériel servant à les faire fonctionner!

De ce fait, certaines politiques d’archivage à long terme doivent envisager d’une part la conversion des informations numériques dans des formats à la fois physiquement durables mais surtout pérennes d’un point de vue logique, c’est à dire en général des formats normalisés, ouverts et bien documentés (comme par exemple le PDF/A ou les formats basés sur XML). Cependant dans certains cas il peut être nécessaire d’envisager la conservation de la donnée originale et son environnement logiciel et matériel afin de garantir la conformité de la restitution ultérieure de l’information.

Ainsi, dans le cadre des recherches sur l’archivage de données à très long terme portant sur la sécurité nucléaire, a été étudié la conservation de systèmes informatiques complets (ordinateurs, consoles, périphériques d’entrées-sorties…), avec les logiciels originaux, pour conserver un accès le plus long possible des données sensibles dans leur configuration originale.

Économie de l’archivage

Un des intérêts de la numérisation des archives est de permettre de nouvelles possibilités d’exploitation. Un exemple bien connu est la mise en ligne des archives de l’INA, de la BNF qui donne accès à tout un chacun à d’immenses ressources documentaires. Pour de nombreux producteurs, éditeurs et ayant-droits, c’est la possibilité d’une amélioration substantielle de la rentabilité des données conservées.

Cette évolution a créé l’espace nécessaire à un vaste marché de l’archivage: de nombreux acteurs publics et privés proposent logiciels, matériels et services pour pratiquement tous les usages.

Les services hébergés sont encore essentiellement limités aux solutions nécessitant peu de débit et de stockage, de type “coffre-fort électronique” (locarchive, arkhinéo, Cecurity) plutôt qu’orientées vers l’archivage massif, encore que certaines solutions commencent à apparaître comme Amazon Glacier (qui reste cependant une plate-forme générique et non une solution intégrée). Les solutions matérielles et logicielles sont trop nombreuses pour être citées extensivement, d’ASG ADA, Active Circle, FrontPorch, Intellique, à XenData et Yoyotta, sans compter les nombreuses solutions proposées par des SSII comme Atos, ou des généralistes comme IBM, HP et Oracle qui ont souvent des gammes complètes de solutions se recouvrant partiellement dans leurs fonctions et leurs usages.

Concernant les services publics français, on citera bien sûr l’INA (archives audiovisuelles), la BNF (archivage texte et image), l’IGN (données cartographiques), le CINES (données scientifiques)…

Politiques d’archivage

Aujourd’hui les bonnes pratiques se calquent généralement sur un modèle normé de type OAIS, qui définit les étapes nécessaires de l’archivage : production, collecte, stockage, administration, consultation… Les acteurs souhaitant archiver leurs données doivent définir leur politique pour chaque opération: qui collecte? à quel moment de la production de données? Quels sont les droits d’accès nécessaires? Qui archive? Comment sont indexées les données? Qui a accès aux informations? Selon quels critères? etc.

La solution logicielle ou le service choisi contraindra fréquemment certains aspects de la politique d’archivage. C’est à la fois un avantage et un inconvénient: un avantage car il est difficile et souvent contre-intuitif pour des non spécialistes de définir ex nihilo tous les aspects d’une politique efficace qui résiste à l’épreuve du temps; un inconvénient parce qu’une solution peut restreindre l’accès à certains choix qui auraient pu être sinon préférés.

On peut définir un ensemble de bonnes pratiques généralisées qui devront être mises en oeuvre dans la mesure possible et qui peuvent vous aider à choisir une solution d’archivage:

0° si possible, concevoir le système d’archivage comme un ensemble logique distinct du système d’information. 1° essayer de collecter au plus près de la production de données. 2° collecter le maximum d’information afférentes aux données (métadonnées). 3° organiser les métadonnées de façon à maximiser les possibilités de recherche (par exemple en utilisant un SGBDR). 4° créer au moins trois copies distinctes, sur deux technologies de supports différentes (par exemple disques durs et bandes magnétiques), dans au moins deux lieux entièrement distincts, ceci afin de garantir la pérennité des données. 5° déterminer quand et comment purger les données: toutes les données ne demandent pas à être conservées indéfiniment. 6° définir à l’avance quand et comment migrer les supports, et éventuellement les formats de données.

Bibliographie

• Mémoire CNAM INTD : « Conduire un projet d’archivage électronique » de Marie Mathias Dronne, 2006
• Rapport APROGED : « La maîtrise du cycle de vie du document numérique », 2006
• « La Gazette du CINES » février 2013, numéro spécial « Archivage numérique pérenne »
• « Economic considerations for long term data retention », Randy Kerns for Evaluator Group, January 2015
• Actes du colloque des Archives Nationales, « Quand l’archivage devient électronique », 5 et 6 février 2013.

Depuis la disponibilité officielle de ZOL (ZFS on Linux) dans la dernière version stable d’Ubuntu, la mode ZFS bat son plein. ZFS est régulièrement présenté depuis de longues années comme la plus belle invention depuis les systèmes de fichiers journalisés.

ZFS il est vrai a de grands avantages: sécurité par l’utilisation systématique de sommes de contrôles en lecture comme en écriture, clichés (snapshots) continus, extension facile, virtualisation des volumes, différents niveau de redondance (miroir, RAIDZ, RAIDZ2, RAIDZ3…), déduplication, etc.

Mais si ZFS a ses avantages, il est nettement orienté vers l’administrateur système compétent, et fournit une ample réserve de fusils à pompe chargés à chevrotine (voire de lance-roquettes) pour se tirer des balles dans le pied. En particulier, de nombreuses manipulations irréversibles ou destructrices de données sont appliquées sans confirmation préalable aucune.

Passons ces points en revue.

Vocabulaire

Avant d’installer ZFS, il convient de se familiariser avec ses concepts. ZFS regroupe plusieurs fonctionnalités habituellement partagées entre plusieurs sous-systèmes, à savoir (sous Linux seulement):

• la redondance (RAID)
• les volumes logiques (LVM)
• le système de fichiers.

Dans la tradition d’administration système Linux, pour obtenir la redondance on créera un volume RAID; pour pouvoir facilement redimensionner des volumes, attribuer des espaces de stockage dédiés à différents usages, prendre des clichés on utilisera LVM; enfin, on installera sur les volumes des systèmes de fichiers.

ZFS amène sa propre logique: on assemble les disques en vdevs, qu’on ajoute à un zpool, qu’on peut partager en volumes (sous-volumes, zvol ou clichés). La redondance (niveau de RAID) se fait au niveau du vdev, mais les clichés se font au niveau du zpool.

ARC, L2ARC et ZIL

ARC est simplement le cache disque de ZFS (dédié). Il n’utilise pas le cache VFS standard du noyau Linux.

L2ARC est un cache en lecture sur SSD. Il permet d’accélérer certaines lectures (aléatoires, petits fichiers…). Les SSD peuvent être relativement bas de gamme, et ils sont stripés.

ZIL est un cache en écriture sur SSD. Il permet d’accélérer les écritures synchrones et/ou aléatoires. Il faut des SSD très rapides, et en miroir. C’est un pur cache en écriture pour des reprises rapides en cas de coupure, etc.

Utilisation de base : créons un zpool

Un vdev est un ensemble de disques (une grappe RAID). Quand on ajoute des disques à un zpool on crée un nouveau vdev avec ces disques. On ne peut pas rajouter de disques à un vdev existant.

Commençons avec une machine sans pools:

# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0   7,3T  0 disk 
sdb           8:16   0   7,3T  0 disk 
sdc           8:32   0   7,3T  0 disk 
sdd           8:48   0   7,3T  0 disk 
sde           8:64   0   7,3T  0 disk 
sdf           8:80   0   7,3T  0 disk 
sdg           8:96   0   7,3T  0 disk 
sdh           8:112  0   7,3T  0 disk 
nvme0n1     259:0    0 119,2G  0 disk 
  nvme0n1p1 259:1    0  29,8G  0 part /
  nvme0n1p2 259:2    0   1,9G  0 part [SWAP]
  nvme0n1p3 259:3    0  87,6G  0 part 

# zpool list
no pools available

Créons le zpool:

# zpool create poolz2 raidz2 sda sdb sdc sdd sde sdf sdg sdh

# zpool list
NAME     SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
poolz2    58T   224K  58,0T         -     0%     0%  1.00x  ONLINE  -

# df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev                16G       0   16G   0% /dev
tmpfs              3,2G     11M  3,2G   1% /run
/dev/nvme0n1p1      30G    5,7G   23G  21% /
tmpfs               16G       0   16G   0% /dev/shm
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs               16G       0   16G   0% /sys/fs/cgroup
tmpfs              3,2G    4,0K  3,2G   1% /run/user/117
tmpfs              3,2G       0  3,2G   0% /run/user/0
poolz2              40T       0   40T   0% /poolz2

# zpool status
  pool: poolz2
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        poolz2      ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0
            sde     ONLINE       0     0     0
            sdf     ONLINE       0     0     0
            sdg     ONLINE       0     0     0
            sdh     ONLINE       0     0     0

errors: No known data errors

Les pièges de la création de zpool:

• il est impossible de retirer un périphérique d’un zpool. Ceci induit deux corollaires:
  • si on se trompe et qu’on met un disque par erreur dans un zpool, par exemple une clef USB, tant pis: ce périphérique doit rester en place aussi longtemps que le zpool sera utilisé…
  • si on se trompe et que le disque inséré contenait des données, tant pis: elles sont irrémédiablement perdues, et ZFS ne demande pas de confirmation.

Conclusion: vérifiez très soigneusement la liste des disques que vous comptez utiliser avant de créer votre zpool.

Création de volumes

ZFS permet de créer très facilement des volumes (simples, ou clichés) à l’intérieur d’un zpool, et les monte automatiquement:

# zfs create poolz2/myshare

# cd /poolz2/myshare/
# ls
# mkdir test/
# mkdir titi tete tata toto
# for i in *; do echo rere > $i/rere; echo zeze > $i/zeze; done
# ls
tata  test  tete  titi  toto
# df -h .
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
poolz2/myshare      57T    128K   57T   1% /poolz2/myshare

par contre, attention au piège: la destruction d’un volume se fait sans le moindre préavis, ni demande de confirmation.

# cd
# zfs destroy poolz2/myshare 
# ls /poolz2/

Conclusion: avant d’utiliser la commande “zfs destroy” soyez très prudent.

Agrandissement de zpool

Il est extrêmement simple d’ajouter un nombre quelconque de disques à un zpool existant:

# zpool add poolz2 raidz2 sdi sdj sdk sdl sdm sdn sdo sdp 

Un piège lié aux précédents se présente lors de l’ajout de disques à un zpool. On serait tenté de croire qu’on peut y rajouter des disques pour l’agrandir au fur et à mesure, et effectivement si on y ajoute un disque ou deux, ZFS agrandira le zpool mais en créant un nouveau vdev à chaque ajout. Or le RAID se fait au niveau du vdev et pas au niveau du pool!

• on ne peut pas ajouter de disques à un vdev, sauf à convertir un vdev d’un seul disque en miroir.
• si on fait du raidz2, on doit ajouter les disques par vdev entiers, par exemple par groupes de 6, 8 ou 10 disques, faute de quoi la performance sera gravement impactée.

Un autre piège est que ZFS ne permet pas, contrairement au RAID logiciel Linux ou à la plupart des contrôleurs matériels, de changer le niveau de RAID d’un vdev ou d’étendre un vdev. Donc…

• si on oublie un disque (on en met 9 au lieu de 10): dommage, il faut casser le zpool et le refaire. J’espère que vous n’y aviez pas encore mis de données…
• si on se trompe de niveau de RAID : là encore c’est bien dommage, il est impossible de modifier un vdev.

Enfin, le piège mortel:

Si on perd un vdev, on perd tout le pool. Si on crée un pool avec un vdev raidz2 et qu’on ajoute un seul disque au pool, ce disque constitue alors un vdev non redondant. Si ce disque tombe en panne, tout le pool est perdu! Cas d’école: sur un serveur avec un zpool contenant 3 pétaoctets de données, on ajoute par erreur une clef USB au zpool. Quelqu’un retire la clef USB. Toutes les données sont perdues.

Clichés

Cela devrait aller sans dire et pourtant, il peut être utile de le répéter : les clichés (snapshots) ne constituent pas des sauvegardes. Un cliché fait partie du même zpool que le volume qu’il réplique : en cas de panne du zpool, les données originales aussi bien que les clichés seront perdues… Faites des sauvegardes!

Pour finir

ZFS est un système complexe pensé par et pour des administrateurs Unix chevronnés, binoclards et barbus qui méprisent les interfaces graphiques.

Il n’est sûrement pas destiné aux “mangeurs de quiche”. Soyez prudents et extrêmement méthodiques en utilisant toute commande commmançant par “zpool” ou “zfs”.

lorsque vous créez ou agrandissez un zpool, vérifiez, vérifiez encore, testez, simulez. La moindre erreur peut causer des pertes massives de données…

LizardFS is a Free Software cloud file system being developed since 2012. It was originally derived from MooseFS, and unlike MooseFS there are no restricted features in the OSS version (high availability metadata server, advanced redundancy management).

Architecture

The file system is structured in a classic way. The different components are:

• the “Chunk Servers” who provide the actual storage. Storage is based on a standard local file system.
• a “Master Server” which takes on the classic role of a metadata server, which manages object naming, access and client orientation to the “chunk” server containing the required data.
• a “Metalogger Server” which manages a list of the operations in progress in order to be able to resume on incident in the event of sudden shutdown of the “Master Server”.
• optionally, one or more “Shadow Servers” which are backup metadata servers, in order to be able to take over from the “Master Server” in the event of a problem.
• and finally the FUSE client which allows to mount the file system locally.

Of course a physical server can simultaneously assume the functions of “Chunk Server” and “Master”, “Metalogger” or “Shadow Server”, as well as being a client.

Local storage will typically rely on RAID arrays. Redundancy at the server cluster level will therefore be added to any local RAID redundancy.

The cluster configuration is quite simple and described in the LizardFS documentation.

Note that it is very easy to set different security modes for different parts of the overall file system. Granularity is done at the folder or even file level.

User Interface

LizardFS is used with fairly simple command line tools, and provides a convenient web interface to monitor the status of the cluster in all its aspects.

The administration essentially uses the lizardfs and lizardfs-admin commands to modify the cluster parameters.

The lizardfs-admin command communicates with the Master Server to change global parameters, for example:

lizardfs-admin list-goals [master ip] [master port]

The lizardfs command applies to file system objects and allows for example to define the redundancy level for a folder, a file, etc. Example:

lizardfs setgoal -r important_file /mnt/lizardfs/IMPORTANT

On the client side, mounting the storage is as simple as follows:

mfsmount -o big_writes,nosuid,nodev,noatime /mnt/lizardfs

To improve reading performance, a few options can be added:

mfsmount -o big_writes,nosuid,nodev,noatime -o cacheexpirationtime=500 -o readaheadmaxwindowsize=4096 /mnt/lizardfs

Overall use is very simple for a seasoned Linux administrator.

The web interface presents all the reports as tabs, it is possible to display several tabs simultaneously by pressing the small “+”. Here are all the screens (click to enlarge):

Tested configuration

The tested configuration includes 5 “Chunk Servers”. One of them is also a Master, another a Metalogger and a third a Shadow Server. All are cluster clients. A sixth identical machine is also used as a client, either via the FUSE LizardFS module, or via Samba sharing of the LizardFS volume from one of the cluster members.

Each machine includes 16 disks of 8 TB aggregated in Linux software RAID (md-raid) a Xeon D1541 2.1 Ghz 8 cores processor and 16 GB of RAM and is connected to the network with 10 Gigabit ethernet.

The disk performance of the standalone servers was measured beforehand:

16x 8Tb RAID-6

• writing: 800 MB/s (CPU constrained)
• reading: 2400 MB/s (1 stream), 1880 MB/s (4 streams)

4 x 8 TB RAID-0

• writing: 1800 MB/s
• reading: 2500 MB/s

In order to compare the relative performance of the local RAID-6 and the different redundancy modes of LizardFS, we performed a first test with disks configured as a RAID-6 array on the servers, and without any redundancy at the cluster level. For the following tests, we reconfigured the disks into 4 RAID-0 arrays of 4 disks, in order to maximize local disk performance, while comparing the different redundancy modes:

• no redundancy: for reference. Obviously not to be used in production!
• x2 replication : each data block is written to two different chunks. It is a “mirror” mode.
• XOR 3+1 : a parity block is created for 3 data blocks. Each of the 4 blocks is then written to a different chunk. It’s equivalent to a “RAID-5” array of servers.
• Erasure Coding 3+2 : two parity blocks are created for 3 data blocks. Each of the 5 blocks is then written to a different chunk. This is equivalent to a “RAID-6”. array of servers.

Tests will focus on sequential performance.

The Tests

Test 1: RAID-0, no redundancy

The purpose of this test is to define maximum performance, limited by network and disk bandwidth. This is our reference point, but of course do not use such a configuration in production, it would be very risky.

Test 2: Local RAID-6, no cluster redundancy

This test evaluates the relative efficiency of the distributed parity calculation at the cluster level compared to a local parity calculation on each server. This mode allows the loss of one or two disks per server, but if an entire server failed the cluster would be inoperable.

Test 3: RAID-0, replication x2

This mode of replication will undoubtedly be favoured for the most important data. It is the simplest and in our case the fastest, especially in reading. The limiting factor here seems to be the network bandwidth between nodes.

Test 4: RAID-0, redundancy XOR 3+1

This redundancy mode allows the failure of a complete chunk (typically a server or RAID volume).

Test 5: RAID-0, redundancy Erasure Coding 3+2

This redundancy mode allows two chunks to fail. Although documentation shows optimal performance in this mode, the high processor load limits performance, especially in writing.

Test 6: Local RAID-6, no redundancy, SMB sharing

The result of this test is to be compared to test 2. Only one client was used, but accessing the volume through an SMB mount rather than using the LizardFS client. Performance is much lower, but still very satisfactory.

Conclusion

The ease of deployment and use of LizardFS makes it a good candidate for very massive storage systems, intended for archiving but also for production. In future tests, we will evaluate the behaviour in case of node failure and cluster extension by adding new systems. It will also be interesting to compare LizardFS to its main competitors.

Long gone is the time when the professionals with high data storage needs could be satisfied with a simple centralised system like a SAN or NAS. Nowadays, everyone’s thinking about cloud, scalable architectures and capacity, redundancy…

Unfortunately the number of software solutions, platforms, open or proprietary systems available to build these newfangled storage systems is growing rapidly. What are the benefits, the downsides of such and such solution? What are they best used for? Why choose this one over this other one? That’s the reason of this series of tests.

What’s a Cloud Filesystem?

A filesystem is a common way to organise data as files in a hierarchical tree of folders, generally adhering to the POSIX model. Usually the filesystem is hosted in a single storage device, lika an SSD, a hard drive or a RAID array (abstracting away a set of physical drives as a virtual, unified storage volume).

A cluster filesystem allows several different computers (called “nodes”) to access the same filesystem (therefore the same folder tree and files). These cluster filesystems are divided into two families: SAN filesystems and Cloud filesystems (some solutions belong to both categories at the same time).

A SAN filesystem allows a set of systems connected through a storage area network (SAN) to share a common storage device (typically a large SAN-oriented RAID storage array), and to work simultaneously on the same tree of files. Redundancy, scalability are managed by the storage array subsysstem. Some known solutions from this family are Quantum StorNext, HP(SGI) CXFS, IBM GPFS, Tiger tech Tiger Store… In the Free Software/OpenSource world, we have RedHat GPFS, Oracle OCFS… This family of filesystems is not what we’ll be discussing here.

A Cloud storage solution gives several computers access to a shared storage volume, but instead of relying upon a shared, distinct storage subsystem, it will instead pool the local storage resources of each cluster member. There are many different cloud storage solutions; some can present their storage as a filesystem, some can’t, but generally offer primarily an “object oriented interface”, particularly targeted towards large internet-based applications, that we won’t treat here. Some have both a filesystem and an object interfaces, but generally in tnat case the object one comes first.

Examples of cloud storage solutions (and their privileged access mode): Scality (object, file connector), Dell/EMC Isilon (file only), OpenIO (object only), CEPH (object, block, file), LizardFS (file), XtreemFS (file), MooseFS (file), RozoFS (file)…

A last group of cluster filesystems offer no data redundancy and are tailored for High Performance Computing and Science applications, they’re for instance Lustre, OrangeFS, BeeGFS, etc. These filesystems won’t be detailed here.

Why use a Cloud Filesystem?

Most cloud filesystems have clear benefits in terms of scalability (ability to add more storage as needed without downtime) and redundancy (immunity to the loss of an entire storage node or even a complete datacentre).

We’ll be concentrating in this comparison on filesystems with the following features:

• ability to add a new node to expand the cluster capacity
• ability to withstand complete failure of at least one node
• ability to rebuild data from a failed node

Most of these filesystems work using a user mode (FUSE) driver. The main benefit of FUSE drivers is that they are often also available for MacOS and Windows, therefore giving native access to the storage cluster to client machines running these operating systems instead of going through an additional file-sharing layer. The main downside of FUSE drivers is that they tend to be less robust than native Linux kernel drivers; for instance under very low memory conditions, the driver may be killed by the “OOM killer”. Another limitation is that a FUSE filesystem cannot be shared using the kernel NFS server, which is faster thant the user-mode NFS server.

The Competitors of this Shoot-out

We plan to test the following Cloud Filesystems:

• LizardFS
• RozoFS
• CEPH FS
• GlusterFS

The goal is to test these in an enterprise storage environment for video production and post-production, archiving, rather than on pure internet-oriented use like massive virtualisation, video streaming, etc.

LizardFS est un système de fichiers en nuage libre développé depuis 2012. Il dérive étroitement de MooseFS, et contrairement à à ce dernier il n’y a pas de fonctionnalités limitées dans la version libre (serveur de métadonnées en haute disponibilité, gestion de redondance avancée).

Architecture

Le système de fichiers est architecturé selon un mode classique. Les différents composants sont:

• les “Chunk Servers” qui fournissent le stockage proprement dit. Le stockage s’appuie sur un système de fichiers local standard.
• un “Master Server” qui tient le rôle classique de serveur de métadonnées, qui gère le nommage des objets, l’accès, l’orientation des clients vers le serveur “chunk” contenant les données recherchées.
• un “Metalogger Server” qui gère une liste des opérations en cours afin de pouvoir reprendre sur incident en cas de coupure brutale du “Master Server”.
• en option, un ou plusieurs “Shadow Servers” qui sont des serveurs de métadonnées de secours, afin de pouvoir prendre le relai du “Master Server” en cas de problème.
  • et finalement le client FUSE qui permet de monter le système de fichiers localement.

Bien sûr un serveur physique peut assumer simultanément la fonction de “Chunk Server” et de “Master”, “Metalogger” ou “Shadow Server”, ainsi qu’être client.

Le stockage local va généralement s’appuyer sur des grappes RAID. La redondance au niveau de la grappe de serveur va donc s’ajouter à une éventuelle redondance RAID locale.

La configuration de la grappe est assez simple et décrite dans la documentation LizardFS.

Notez qu’il est très facile de définir des modes de sécurité différents pour différentes parties du système de fichiers global. La granularité s’effectue au niveau du dossier ou même du fichier.

Interface utilisateur

LizardFS s’utilise avec des outils en ligne de commande assez simples, et fournit une interface web commode pour surveiller l’état de la grappe dans tous ses aspects.

L’administration utilise essentiellement les commandes lizardfs et lisardfs-admin pour modifier les paramètres de la grappe.

La commande lizardfs-admin communique avec le Master Server pour modifier les paramètres globaux, par exemple:

lizardfs-admin list-goals  

La commande lizardfs s’applique à des objets du système de fichiers et permet par exemple de définir le niveau de redondance pour un dossier, un fichier, etc. Exemple:

lizardfs setgoal -r important_file /mnt/lizardfs/IMPORTANT

Côté client, le montage se résume à :

mfsmount -o big_writes,nosuid,nodev,noatime /mnt/lizardfs

Pour améliorer les performances en lecture, on pourra ajouter quelques options:

mfsmount -o big_writes,nosuid,nodev,noatime -o cacheexpirationtime=500 -o readaheadmaxwindowsize=4096 /mnt/lizardfs

L’utilisation est globalement très simple pour un administrateur Linux.

L’interface web présente l’ensemble des états sous forme d’onglets, il est possible d’afficher plusieurs onglets simultanément en appuyant sur le petit “+”. Voici l’ensemble des écrans (cliquez pour agrandir):

Configuration testée

La configuration testée comprend 5 “Chunk Servers”. Un d’entre eux est également “Master”, un autre “Metalogger” et un troisième “Shadow Server”. Tous sont clients de la grappe. Une sixième machine identique est également utilisée comme client, soit via le module FUSE LizardFS, soit via un partage Samba du volume LizardFS depuis un des membres de la grappe.

Chaque machine comporte 16 disques de 8 To agrégés en RAID logiciel Linux (md-raid) d’un processeur Xeon D1541 2,1 Ghz 8 cœurs et de 16 Go de RAM et est connectée au réseau en 10 Gigabit ethernet.

La performance disque des serveurs seuls a été mesurée préalablement :

RAID-6 de 16x 8 To

• écriture : 800 Mo/s (limité par le processeur)
• lecture : 2400 Mo/s (1 flux), 1880 Mo/s (4 flux)

4 RAID-0 de 4x 8 To

• écriture : 1800 Mo/s
• lecture : 2500 Mo/s

Afin de comparer la performance relative du RAID-6 local et des différents mode de redondance de LizardFS, nous avons effectué un premier test avec les disques en RAID-6 sur les serveurs, et sans redondance au niveau de la grappe. Pour les tests suivants, nous avons reconfigurés les disques en 4 grappe RAID-0 de 4 disques, afin de maximiser la performance disque locale, afin de comparer les modes de redondances suivants:

• aucune redondance : pour référence. Évidemment à ne pas utiliser en production!
• réplication x2 : chaque bloc de données est répliqué sur deux “chunks” différents. C’est un mode “miroir”.
• XOR 3+1 : un bloc de parité est créé pour 3 blocs de données. Chacun des 4 blocs est écrit sur un “chunk” différent. C’est équivalent à un “RAID-5 de serveurs”
• Erasure Coding 3+2 : deux blocs de parité sont créés pour 3 blocs de données. Chacun des 5 blocs est écrit sur un “chunk” différent. C’est équivalent à un “RAID-6 de serveurs”.

Les tests se concentreront sur la performance séquentielle.

Les Tests

Test 1: RAID-0, pas de redondance

Le but de ce test est de définir une performance maximum, limitée par la bande passante réseau et disque. C’est notre point de référence, mais bien entendu n’utilisez pas une telle configuration en production, ce serait très risqué.

Test 2: RAID-6 local, pas de redondance de grappe

Ce test permet d’évaluer l’efficacité relative du calcul de parité réparti au niveau de la grappe par rapport à un calcul de parité local sur chaque serveur. Ce mode autorise la perte d’un ou deux disques par serveur, par contre en cas de panne d’un serveur entier la grappe sera inopérante.

Test 3: RAID-0, réplication x2

Ce mode de réplication sera sans doute favorisé pour les données les plus importantes. Il est le plus simple et dans notre cas, le plus rapide, surtout en lecture. Le facteur limitant semble être ici la bande passante réseau entre les nœuds.

Test 4: RAID-0, redondance XOR 3+1

Ce mode de redondance autorise la panne d’un “chunk” complet (typiquement, un serveur ou un volume RAID).

Test 5: RAID-0, redondance Erasure Coding 3+2

Ce mode de redondance autorise la panne de deux “chunks”. Bien que la documentation fasse état d’une performance optimale dans ce mode, la forte charge processeur limite la performance, particulièrement en écriture.

Test 6: RAID-6 local, pas de redondance, partage SMB

Le résultat de ce test est à comparer au test 2. Un seul client a été utilisé, mais accédant au volume via un montage SMB plutôt qu’en utilisant le client LizardFS. La performance est nettement inférieure, mais encore très satisfaisante.

Conclusion

La facilité de déploiement et d’utilisation de LizardFS en font un bon candidat pour des systèmes de stockage très massifs, destinés à l’archivage mais également à la production. Lors de prochains tests, nous évaluerons le comportement en cas de panne de nœud et d’extension de la grappe par ajout de nouveaux systèmes. Il sera également intéressant de comparer LizardFS à ses principaux concurrents.

Le temps est révolu où les professionnels aux besoins de stockage importants pouvaient se contenter d’un simple système centralisé de type NAS ou SAN. Désormais, tout le monde pense nuage, architecture scalable, montée en charge, redondance…

Malheureusement il existe un nombre sans cesse croissant de logiciels, de plate-formes, de systèmes ouverts ou propriétaires pour construire ces systèmes de stockage de nouveau style. Quels en sont les points faibles, les points forts, le cadre d’utilisation? Pourquoi choisir un tel plutôt que tel autre? Voilà le but de ce comparatif.

Qu’est ce qu’un système de fichiers en nuage?

Un système de fichiers est une organisation de données selon le modèle bien connu de l’arborescence contenant dossiers et fichiers, généralement suivant le modèle POSIX, avec des variations. Dans le cas général, un système de fichier est contenu dans un seul périphérique de stockage, que ce soit un SSD, un disque dur ou un volume RAID (ce dernier faisant l’abstraction entre un agrégat de disques et un périphérique physique virtuel).

Un système de fichiers en grappe (cluster) permet à plusieurs machines (ou nœuds) d’accéder à un même système de fichier (donc la même arborescence et les mêmes fichiers). Ces systèmes de fichiers en grappe se partagent en deux grands groupes: les systèmes de fichier SAN et les systèmes de fichier en nuage (certains systèmes appartenant aux deux catégories en même temps).

Un système de fichiers SAN permet à un ensemble de machines reliées à un réseau de stockage de partager un périphérique de stockage commun (typiquement, une baie de stockage SAN) et d’y travailler simultanément sur la même arborescence et les mêmes fichiers. La redondance, la scalabilité sont entièrement déléguées au sous-système de stockage SAN. Des exemples de ce type de systèmes sont Quantum StorNext, HP(SGI) CXFS, IBM GPFS, Tiger tech Tiger Store… En logiciel libre nous avons RedHat GPFS, Oracle OCFS… Ce n’est pas notre sujet actuel.

Un système de stockage en nuage permet, à plusieurs machines d’accéder à un volume de stockage commun, mais au lieu de passer par un sous-système de stockage partagé, en s’appuyant sur la mise en commun des ressources de stockage individuelles de chaque machine. Il existe un grand nombre de systèmes de stockage en nuage; certains offrent la possibilité de présenter le stockage sous forme de système de fichiers, d’autres non. Ces derniers présentent généralement uniquement une interface “objet”, destinée à des usages Internet de stockage de données massives, et ne seront pas traités ici. Certains sont à la fois objet et système de fichiers, mais privilégient généralement le mode objet.

Exemples de stockage en nuage (et leur mode d’accès): Scality (objet, passerelle fichier), Dell/EMC Isilon (fichier seulement), OpenIO (objet seulement), CEPH (objet, bloc, fichier), LizardFS (fichier), XtreemFS (fichier), MooseFS (fichier), RozoFS (fichier)…

Une dernière catégorie de systèmes de fichiers agrégeant l’espace de plusieurs machines n’offre pas de redondance et sont destinés au calcul intensif et scientifique, ce sont entre autre Lustre, OrangeFS, BeeGFS, etc. Ces systèmes de fichiers ne seront pas traités ici.

Pourquoi un système de fichiers en nuage?

La plupart des systèmes de fichiers en nuage présentent de gros avantages en terme de scalabilité (possibilité d’agrandir le stockage au fil de l’eau) et de redondance.(tolérance à la panne d’un serveur voire d’un centre de données entier).

Tous les systèmes de notre comparatif offrent au moins les capacités suivantes:

• ajout d’un nœud de stockage à chaud pour étendre la capacité
• tolérance à la panne d’un nœud de stockage
• reconstruction d’un nœud de stockage défaillant

La plupart de ces systèmes de fichiers fonctionnent en mode utilisateur (pilote FUSE). L’avantage des pilotes FUSE est qu’ils sont généralement disponibles également pour MacOS et Windows, permettant ainsi aux clients d’accéder directement au système de fichier de façon native. L’inconvénient des pilotes FUSE est qu’ils sont généralement moins robustes que les pilotes natifs intégrés au noyau Linux, en particulier ils sont susceptibles, dans des conditions de charge mémoire importante, d’être arrêtés de force par le “OOM Killer”. De plus, les pilotes FUSE ne permettent pas le partage du système de fichier via le serveur NFS intégré au noyau, qui est plus performant que le serveur NFS en mode utilisateur.

Les concurrents de notre comparatif

Nous avons prévu de tester les systèmes de fichier en nuage suivants:

• LizardFS
• RozoFS
• CEPH FS
• GlusterFS

L’optique est de tester ces systèmes de fichiers dans un usage entreprise de type stockage de production vidéo, archivage plutôt que pour les usages internet purs type virtualisation massive, diffusion en streaming, etc.

Les supports et bibliothèques de bandes au format LTO-8 commencent à être disponibles. Le LTO-8 apporte des changements significatifs par rapport aux habitudes qui ont prévalu depuis les origines du format en 2001. Pour la première fois, les règles de compatibilité descendante ont changé.

LTO-2 à LTO-7

Du LTO-2 de 2003 jusqu’au LTO-7 de fin 2015, chaque génération de LTO pouvait lire et écrire le format de la génération précédente, et lire deux générations en arrière. Le LTO-7 peut donc lire et écrire les médias LTO-7 et LTO-6, et lire seulement les LTO-5.

Pour rappel, les cartouches LTO-5 ont une capacité native de 1,5 To, les cartouches LTO-6 de 2,5 To, les LTO-7 de 6 To et enfin les LTO-8 12 To.

LTO-8

Le LTO-8 rompt avec cette tradition: en effet si les lecteurs LTO-8 pourront tous lire et écrire les supports LTO-7 et LTO-8, mais ne pourront pas lire les LTO-6.

De plus, les librairies LTO-8 pourront généralement formater les médias LTO-7 en format LTO-8 type M, et ce en fonction du code-barre accolé à ce média: un média LTO-7 vierge dont le code-barre de l’étiquette se termine par “M8” sera formaté en “8 type M”. Sinon, il sera formaté en LTO-7.

Les supports pour le LTO-8 auront donc les capacités suivantes avec un lecteur LTO-8:

Média	Format	Capacité
LTO-7	LTO-7	6 To
LTO-7	“M8”	9 To
LTO-8	LTO-8	12 To

Et ensuite?

• une bande LTO-7 formatée en “M8” ne sera pas lisible sur un lecteur LTO-7.
• une bande LTO-7 formatée en “M8” ne sera pas, c’est d’ores et déjà connu, lisible par un lecteur LTO-9.
• de l’information précédente, on peut sans doute anticiper que le LTO-9 ne sera probablement pas compatible non plus avec le LTO-7, mais proposera vraisemblablement un formatage “M9” des médias LTO-8.

Deux nouvelles séries de bugs de sécurité très important liés aux processeurs ont été publiés en ce début d’année, “Meltdown” et “Spectre”.

Ces bugs sont matériels, impactent plus ou moins les processeurs Intel, AMD et ARM. Tous les systèmes d’exploitation (Linux, Windows, BSD, MacOS, Android, iOS…), tous les types de matériels (PC, Mac, serveurs, téléphones, tablettes…) sont impactés

Le laboratoire de sécurité de Google a démontré une preuve de concept d’attaque utilisant un code Javascript chargé depuis une page Web ordinaire. Depuis, Mozilla Firefox et Google Chrome ont été mis à jour afin de mitiger ces attaques, assurez-vous d’utiliser un navigateur à jour.

Le site linuxfr.org offre une présentation détaillé et des liens vers de nombreux articles ici.

Systèmes Intellique

La grande majorité des systèmes Intellique actuellement en production sont basés sur des processeurs AMD Opteron. Ils sont donc immunisés contre Meltdown, mais vulnérable à Spectre. Des noyaux corrigés en version 4.4.110 et 4.9.75 sont d’ores et déjà disponibles dans les dépôts intellique, branche unstable.

Dans la mesure où un système n’est pas accessible depuis Internet, le risque d’une attaque est pour l’instant infime. Il n’est donc pas forcément nécessaire de se précipiter pour mettre à jour.

Impact sur les performances

Meltdown semble avoir un impact très important sur les performances des processeurs Intel dans certaines conditions. Les correctifs ralentissent fortement les appels systèmes, ce qui impactera plus fortement les systèmes serveurs que les postes utilisateurs. Chez Epic Games, une augmentation considérable de la charge processeur a été constatée après application des correctifs sur les serveurs applicatifs.

source

Spectre pourrait impacter significativement les performances en entrées-sorties, disques et réseau en particulier, sur les serveurs de fichiers. Nous sommes en train de mener des évaluation sur Opteron et Xeon. Les tests préliminaires indiquent que les performances sont peu impactées.

D’aucuns déplorent la simplicité des droits Unix comparés aux 11 (ou 17) ACLs de NTFS. Pourtant il y a déjà pas mal d’occasions de s’amuser… et de se tirer une balle dans le pied.

La base

Les droits Unix de base sont lecture, écriture, exécution. Ces droits peuvent s’appliquer à trois catégories d’utilisateurs: le propriétaire du fichier, le groupe, enfin tous les autres. Ces différents droits sont encodés sous la forme de 3 valeurs octales, une 4e valeur fournissant les “bits spéciaux”. Ainsi, l’ensemble des droits d’un fichier est commodément stocké dans 12 bits, chaque bit indiquant un des droits. On peut donc appliquer ou lire les droits soit en utilisant leurs noms (les lettres r,w,x,s et t):

$ chmod rwxrxrx fichier

Soit en utilisant directement les valeurs en octal correspondantes aux différentes positions des différents bits:

$ chmod 644 fichier

Exemples

Exécutons les commandes suivantes:

mkdir testdir
ls -ld testdir

Nous obtenons ceci:

drwxr-xr-x 2 storiq users 4096 déc.   1 16:07 testdir/

Ajoutons une explication détaillée:

# droits   nombre d'éléments    propriétaire    groupe  taille  date de modification    nom
drwxr-xr-x      2               storiq          users   4096    déc.   1 16:07          testdir/

Aujourd’hui nous nous intéressons aux droits, à savoir la séquence “drwxr-xr-x” Le “d” au début indique qu’il s’agit d’un dossier (et non d’un fichier ordinaire). Les trois lettres suivantes rwx indiquent les droits du propriétaire, à savoir r pour lecture, w pour écriture, et x pour exécution. Les 3 signes suivants r-x indiquent que les membres du groupe users ont le droit de lecture et d’exécution, mais pas d’écriture. Les trois derniers r-x indiquent les droits pour le reste du monde (hors du propriétaire, des membres du groupe “users”, et bien sûr de l’administrateur “root” qui lui de toute façon fait ce qu’il veut).

Les dossiers sont un peu spéciaux, en ceci qu’ils doivent être porteurs de l’autorisation d’exécution pour pouvoir en lister le contenu. ce qui peut déjà donner de belles occasions de se tirer une balle dans le pied:

$ touch super hyper mega
$ ls -l
total 0
-rw-r--r-- 1 storiq users 0 déc.   1 16:20 hyper
-rw-r--r-- 1 storiq users 0 déc.   1 16:20 mega
-rw-r--r-- 1 storiq users 0 déc.   1 16:20 super
$ chmod -x .
$ ls -l
/bin/ls: impossible d'ouvrir le répertoire '.': Permission non accordée

Ou encore:

$ mkdir testdir
$ chmod 666 testdir # tout le monde peut donc lire et écrire
$ cd testdir
bash: cd: testdir: Permission non accordée

Donc prudence lorsqu’on fait des choses comme chmod -R 666 chemin/… Ce n’est probablement pas ce que vous vouliez faire.

Concernant les fichiers ordinaires (fichiers, programmes…) l’utilisation de chmod est un peu moins risquée, encore que…

# chmod -x /usr/bin/chmod
# chmod 
bash: /usr/bin/chmod: Permission non accordée

Les bits setuid et setgid

‘setuid’ signifie “set user id”, et ‘setgid’ “set group id”.

Le “sticky bit”

Se sortir d’une situation difficile

Si par malheur vous avez rendu non exécutable un programme, par exemple…. ‘chmod’:

$ /lib64/ld-linux-x86-64.so. /usr/bin/chmod
/usr/bin/chmod: missing operand

Si vous avez ajouté un utilisateur à un groupe mais que vous ne souhaitez pas relancer la session, utilisez ‘newgrp’ pour qu’il puisse accéder aux fichiers dont il a besoin.

Les SSD au format M.2 sont bien commodes: ils sont compacts, rapides, et la plupart des systèmes récents ont le connecteur ad hoc disponible. Cependant il y a quelques pièges à contourner.

(image thessdreview.com)

Il existe deux types de connecteurs femelles (côté carte mère) et deux types de connecteurs mâles (côté SSD). Comme de bien entendu, ce ne sont pas les mêmes, ce serait trop simple! Les cartes mères sont dotées soit d’un connecteur de type B, soit d’un connecteur de type M (le plus courant). Les SSD, eux, sont dotés soit d’un connecteur de type B&M (le plus courant), soit d’un connecteur de type M. Théoriquement il pourrait exister des SSD à connecteur B mais je n’en ai jamais vu.

(image Wikipedia).

Les SSD M.2 peuvent implémenter deux protocoles différents:

• SATA (pilote AHCI)
• PCIe (pilote NVMe)

Maintenant, voyons comment tout cela s’ajuste…

Côté carte mère

Si le connecteur est un type M, le mode PCIe est supporté (en 4 voies). Le mode SATA, pas forcément. Si le connecteur est un type B, le mode SATA est supporté. Le mode PCIe sera supporté plutôt en 2 voies.

Côté SSD

Si le connecteur est un type M, le mode PCIe est supporté. Le mode SATA, sans doute pas. Si le connecteur est un type B&M, tout est possible. Certains ne supportent que le SATA, d’autres supportent le SATA et le PCIe en 4 voies, ou en 2 voies.

Problème?

En général, un SSD à connecteur M mâle fonctionnera en PCIe (donc très vite) sur une carte mère à connecteur M femelle.

Par contre, horresco referens, un SSD B&M rentrera dans n’importe quel connecteur, mais peut aussi bien fonctionner à pleine vitesse (NVMe), à vitesse réduite (SATA) ou … pas du tout, si le connecteur de la carte mère est un M supportant uniquement le PCIe et le SSD un modèle supportant uniquement le SATA (cas de la plupart des SSD bas de gamme).

Conclusion…

Si vous voulez être sûr de vous, vérifiez bien les modes supportés par votre carte mère et par le SSD qui vous intéresse. Dans le doute, prenez du connecteur M des deux côtés, c’est plus sûr…

Un débat terrible agite la toile. Doit-on nommer le protocole de partage de fichiers Windows CIFS ou SMB? Voir par exemple cet article

Windows

Dans l’univers Microsoft, c’est clair: CIFS fait référence à d’anciennes versions telles que celles utilisée par Windows 95, et correspond à l’implémentation par Microsoft du protocole SMB en version 1.0. On ne doit donc plus jamais utiliser CIFS, seulement SMB, de préférence en version 3.0 ou plus.

MacOS

Dans l’univers Apple macOS (anciennement Mac OS X), pas de problème non plus: on peut utiliser depuis le Finder (Command+k) indifféremment les formes cifs://serveur/partage comme smb://serveur/partage; en ligne de commande, on utilisera

mount -t smbfs //serveur/partage /point/de/montage

Commande qui en sous-main, appelera Library/Filesystems/cifs.fs/Contents/Resources/mount_smbfs. Tout cela est logique et cohérent.

Linux

Hélas, dans l’univers Linux, ça se gâte: il y a fort longtemps, on accédait aux partages SMB (CIFS, en général, si vous me suivez bien…) grâce à smbmount qui ne supportait que la version 1.0 du protocole SMB et était fort bogué. smbmount est complètement obsolète depuis au moins 2007 et a été remplacé par… mount.cifs, qui lui implémente le protocole SMB jusqu’en version 3.02 à l’heure où j’écris ces lignes. Non seulement le nom .mount.cifs semble laisser penser que “CIFS est supérieur à SMB”, mais la page de manuel de mount.cifs entretient l’erreur, puisqu’elle indique franchement que CIFS = SMB2 (ce qui est manifestement erroné, on l’a vu plus haut).

Citation de man mount.cifs :

The CIFS protocol is the successor to the SMB protocol and is supported by most Windows servers and many other commercial servers and Network Attached Storage appliances as well as by the popular Open Source server Samba.

La page man fait également plusieurs fois référence au protocole “CIFS/SMB2”.

Du coup, dans l’univers Linux il est courant de penser que CIFS = SMB2 alors que … non.

---

Voici quelques petites astuces utiles avec le shell Bash. Faites-en profiter vos amis!

Tout d’abord, il est souvent bien utile de lister uniquement les dossiers. Il suffit de rajouter cette petite fonction dans votre .bashrc:

    function lsd {
        ls -1p $* | grep '/$'
    }

Il vous arrive sûrement d’avoir des problèmes d’édition de ligne, de retour à la ligne ou d’affichage de la ligne courante quand vous redimensionnez votre terminal. Voici quelques commandes qui peuvent vous aider: Tout d’abord, bien sûr, commencez avec

reset

Alternativement, vous pouvez aussi utiliser

shopt -s checkwinsize

Vous pouvez améliorer la situation en définissant cette variable d’environnement (vous pouvez aussi les mettre dans votre .bashrc):

export HISTCONTROL=ignoredups:erasedups

ou

export HISTCONTROL=ignoreboth

Pour éditer les commandes un peu trop longues, il est plus commode de passer par l’éditeur. Si vous avez laissé bash configuré par défaut en mode Emacs, pensez qu’il suffit de faire Ctrl+x Ctrl+e pour ouvrir la ligne en cours dans l’éditeur définit dans $EDITOR.

Si vous voulez éditer la dernière commande entrée, entrez simplement la commande

fc

.

Pour mémoire, les disques rempli d’hélium consomment nettement moins d’énergie que leurs équivalents “air”. Ils sont également plus durables; ils sont d’ailleurs garantis 5 ans, contre 3 pour les “air”.

Pour l’instant, HGST conserve encore l’exclusivité de cette technologie. Les WD “Gold” sont en réalité des HGST rebadgés. Seagate a annoncé l’arrivée de disques hélium, mais on ne les verra pas avant plusieurs mois, au moins.

---

article paru dans le numéro 366 de “la revue des ingénieurs ESME SUDRIA”

Le stockage, la sauvegarde et l’archivage peuvent recourir à tous types de supports: disques durs, bandes, disques optiques, mémoires flash, mais c’est bien l’approche applicative qui définit s’il s’agit de stockage, de sauvegarde ou d’archivage.

---

Les techniques de protection des données et leurs usages

Il est souvent délicat pour le néophyte de distinguer les domaines d’applications des différentes techniques de stockage et de protection des données, aussi bien les technologies matérielles que logicielles, ou leur mise en oeuvre en un workflow cohérent.

Les architectures des systèmes de stockage tournent autour de trois concepts:

• les supports : disques durs (intégré au lecteur), bandes magnétiques, disques optiques, mémoires flash.

• les lecteurs : disques durs, lecteurs de bandes, lecteurs optiques, “disques” SSD. Non détaillés dans cet article.

• les sous-systèmes matériels : systèmes RAID, bibliothèque de bande, bibliothèque de disques optiques, stockage objet dit cloud.

---

Les supports de stockage

Disques durs

Le disque dur est sans doute le composant de stockage le plus connu. Il s’agit d’un système d’enregistrement magnétique sur des plateaux (généralement d’aluminium) tournants et accédés par des têtes de lecture/écriture positionnées par un bras oscillant. Contrairement à une légende tenace, les disques durs ne sont jamais sous vide; au contraire, une pression interne minimale est nécessaire à leur bon fonctionnement, la tête de lecture utilisant l’effet venturi afin de conserver une distance optimale à la surface du plateau.

Il existe maintenant des disques durs de 6 et 8 To emplis d’hélium plutôt que d’air. La fluidité de l’hélium réduit les frottements et permet une baisse de la consommation d’énergie d’environ 40%.

Il existe également des disques utilisant la technologie SMR (Shingled Magnetic Recording) dans la quelle les pistes successives se recouvrent légèrement, ce qui permet d’augmenter la capacité (jusqu’à 10 To); par contre il est très difficile de modifier une donnée déjà enregistrée, ces disques sont donc destinés à des applications particulières (stockage à long terme, archivage).

Mémoire flash

La mémoire flash est sans doute le système de stockage de données le plus répandu aujourd’hui, puisqu’il est présent dans les centaines de millions de téléphones mobiles et de plus en plus d’ordinateurs portables. La mémoire flash ne présentant pas de parties mobiles contrairement aux disques durs, elle est insensible aux chocs, tout en présentant d’excellentes performances. Ses principaux inconvénients sont son rapport capacité/prix défavorable, et sa résistance à l’usure (on ne peut récrire une “cellule” qu’un nombre limité de fois).

La mémoire flash est donc rarement utilisée dans des systèmes de stockage massif, sinon comme cache rapide pour un ensemble basé sur des disques magnétiques.

Bandes magnétiques

Et oui, la bande magnétique résiste encore et toujours. Les grands constructeurs IBM, HP et Quantum ont défini à la fin des années 90 un standard commun dit LTO (Linear Tape Open) qui aujourd’hui à la 6e génération (2,5 To natifs par cartouche), est le format de très loin le plus répandu. La bande magnétique présente des caractéristiques intéressantes: le support est peu cher comparé aux disques magnétiques, il est conçu pour se conserver très longtemps (les supports LTO sont garantis 10 ans sous certaines conditions) et il consomme peu d’énergie. Si le LTO présente une performance intéressante (environ 150 Mo/s pour le LTO 6), bien entendu le principal inconvénient reste l’accès séquentiel aux données enregistrées qui peut entraîner des temps d’accès très élevés (plusieurs dizaines de secondes).

disques optiques

Les disques optiques sont aujourd’hui en perte de vitesse du fait de leur faible capacité et leur faible vitesse. Sony cependant propose actuellement un format ODA (Optical Disc Archive) qui présente des capacités jusqu’à 1 To par cartouche. Le principal attrait du disque optique réside dans sa longévité: l’ODA est donné pour pouvant se conserver 50 ans. La vitesse de lecture et d’écriture, par contre, reste limitée, aux environs de 40 à 50 Mo/s.

Pour plus de considérations sur les supports de stockage, et en particulier des détails techniques sur les disques magnétiques et SSD, voir http://fr.slideshare.net/eflorac/prsentation-stockage

---

Sous-systèmes

Système RAID

un assemblage RAID (Redundant Array of Inexpensive Drives) est un assemblage logique de disques durs ou de SSD résistant à la panne. Le fait de regrouper logiquement un ensemble d’éléments augmente bien entendu la probabilité de panne, pour s’en protéger le système RAID soit duplique les données (RAID 1, RAID 10) soit calcule des données de parité permettant de reconstituer une donnée qui viendrait à manquer (RAID 5,6) à partir des données restantes.

Les modes de RAID les plus couramment utilisés sont le RAID 1 ou 10 (miroir) et le RAID 6. Il convient de considérer le RAID 5 comme obsolète pour les capacités des disques durs actuels. Voir http://blogs.intellique.com/tech/2012/10/31#Raid5-est-mort

L’utilisation du RAID présente donc les avantages suivants: - augmentation de la capacité : il n’existe pas de disques durs de 24 To, mais le RAID permet d’assembler par exemple 8 disques de 4 To et de les présenter comme un seul volume de 24 To utiles. - augmentation de la performance : l’assemblage de 8 x 4 To donné en exemple sera environ 6 fois plus performant qu’un seul disque de 4 To. - continuité de service : en cas de défaillance d’un disque, le remplacement de celui-ci se fait sans interruption.

L’utilisation du RAID ne protège pas contre la malveillance, les erreurs humaines, ou les incidents de plus grande ampleur; s’il y a un incendie dans la salle serveur, ou une inondation, le RAID ne permettra ni de garantir la continuité de service, ni la reprise d’activité. L’utilisation du RAID ne constitue donc pas une stratégie de sauvegarde, ni d’archivage.

Pour plus de détails sur les différents modes de RAID, voir http://fr.slideshare.net/eflorac/prsentation-du-stockage-raid

Bibliothèque de bandes ou disques optiques

Une bibliothèque de bande ou de supports optiques est un système contenant un certain nombre de supports (allant de 8 à plusieurs milliers), un certains nombre de lecteurs pour ces supports et un bras robotisé permettant de charger et décharger les supports dans les lecteurs à la demande.

Les bibliothèques de ce type présentent l’avantage de contenir une masse de données très importantes accessible de manière entièrement automatisée. De plus, ces systèmes consomment très peu d’énergie.

L’inconvénient principal réside dans le temps d’accès important (typiquement quelques minutes) et l’adressage indirect, qui implique en général une couche logicielle de gestion sophistiquée.

stockage objet dit Cloud

La volumétrie des données croissant sans cesse et leur mode d’utilisation évoluant, de nouvelles approches sont apparues pour la gestion de stockage extrêmement massif. Les systèmes de type “stockage objet” tel que Ceph, Gluster, Scality… visent à assurer la disponibilité des données par la réplication, en suivant un mode de découpage et de répartition des données qui permet de supporter non seulement la panne d’un composant (tel un disque dur) mais aussi d’un sous-système arbitrairement grand (un serveur de stockage, une baie de serveurs, voire un centre de données). L’avantage principal de ces systèmes est de permettre d’accroître l’espace de stockage par ajout de nouveaux sous-systèmes, et de réformer les éléments obsolètes simplement, sans jamais nécessiter de migration globale des données.

Ces nouveaux systèmes ne sont intéressants en terme d’investissement qu’au delà de 1 Po de données, mais ils se démocratisent rapidement.

---

Applications logicielles

Différentes catégories d’applications de gestion du stockage

virtualisation de stockage

Les applications de virtualisation de stockage permettent de présenter aux utilisateurs ou aux applications des volumes de stockage virtuels décorrélés de l’organisation physique des systèmes de stockage. Elles permettent également fréquemment de déplacer les données utilisées le plus fréquemment vers les systèmes de stockage les plus performants, et les données peu utilisées vers des systèmes moins coûteux voire “dormants” (sur bande). Historiquement les premiers systèmes de ce type ont été les HSM (Hierarchical Storage Manager) qui permettent d’utiliser une bibliothèque de bande comme extension transparente d’un système de stockage sur disque: les fichiers peu utilisés sont stockés sur bande, et chargés à la demande, le début du fichier étant conservé sur disque.

clichés

Les clichés (ou snapshots) sont un mécanisme généralement intégré aux systèmes de fichiers (Oracle ZFS, NetApp WAFL…) ou aux gestionnaires de volume (Symantec VxVM, Linux LVM…). Ce mécanisme permet de “figer” l’état du volume ou du système de fichier à un instant donné. Ainsi, les fichiers effacés après la prise du “cliché” restent présents dans celui-ci. Ce système est fréquemment employé comme premier niveau de sauvegarde de données.

gestionnaire de versions

Les gestionnaires de version sont une gamme d’outils permettant de conserver les versions successives d’un ensemble de fichiers après chaque modification. Généralement l’enregistrement est explicite via une commande dite de commit ou check-in.La plupart des gestionnaires de versions sont utilisés dans un environnement de développement logiciel coopératif, afin de permettre aux différents développeurs de partager leurs modifications successives de code.

• Les systèmes historiques : RCS, CVS
• Les systèmes propriétaires: Perforce, Microsoft SourceSafe
• Le système libre dominant jusqu’à récemment: Subversion (svn)
• Les systèmes distribués: git (Linux), Mercurial, Bazaar.

Sauvegarde

La sauvegarde vise à protéger les données de deux aspects non couverts par la simple redondance matérielle, à savoir les erreurs humaines (“oups, je n’aurai pas du faire ça”) et les accidents de plus grande ampleur comme les incendies, inondations, etc. afin de maintenir idéalement la continuité de service, ou à défaut une reprise d’activité aussi rapide que possible.

Pourquoi sauvegarder? Parce que les données sont absolument critiques dans toute entreprise! Une étude Infocorp de 2002 indique que 30% des entreprises subissant une perte de données faisaient faillite.

Une bonne sauvegarde trouve la péréquation entre coût et risque afin de se protéger suffisamment. Elle suppose en général 1° une copie complète des données faite aussi souvent que possible 2° un historique suffisant pour pouvoir revenir en arrière en cas de problème non immédiatemment détecté 3° au moins une copie distante, en cas de problème grave sur le site de production.

Les applications et systèmes de sauvegarde sont innombrables, aussi bien sous forme de matériel, de logiciel que de services “cloud”. Quoi qu’il en soit:faites des sauvegardes!

Archivage

Distinction entre la sauvegarde et l’archivage

La sauvegarde est destinée à protéger les données indispensables à la production; elle sécurise les données selon différentes stratégies mais ne prétend pas garantire la disponibilité à long terme des données, typiquement au delà d’un an. L’archivage propose au contraire de garantir la disponibilité des données sur le long terme.

On distingue deux approches: l’archivage patrimonial visant à conserver l’information sur une durée illimitée ( Ce qui implique non seulement de protéger la donnée, mais également les éléments nécessaires à son exploitation ou son interprétation, y compris parfois les éléments matériels ). L’archivage à valeur probante destiné à garantir l’intégrité et l’authenticité des données, généralement sur une durée définie de façon réglementaire et rarement supérieure à 10 ans (factures, contrats, etc). C’est ce que recouvrent les solutions dites “coffre-fort électronique”.

Admettons que (suite à une coupure de courant, un bloc de disque dur défectueux, une erreur de manipulation ou autre) que votre système ne démarre pas, parce que la table de partition est corrompue. Le problème peut se manifester de plusieurs façons, par exemple le chargeur de démarrage GRUB reste coincé sur “Loading GRUB stage 1.5”, ou bien parfois le chargeur de démarrage parvient à charger le noyau, mais celui-ci s’arrête avec “No root found”, puis vous lâche dans le Busybox de l’initrd; après quoi la commande cat /proc/partitions renvoie quelque chose comme:

major minor  #blocks  name

   8       16  488386584 sda

Dépité, vous démarrez sur un système de secours et vous lancez parted sur votre disque:

parted /dev/sda
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print                                                            
Error: The primary GPT table is corrupt, but the backup appears OK, so that will be used.
OK/Cancel? OK                                                             
Model: ATA ST3500630AS (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size     File system     Name     Flags
 1      1049kB  24,7GB  24,7GB   ext4            root
 2      24,7GB  25,8GB  1096MB   linux-swap(v1)
 5      24,7GB  500GB  1096MB    xfs

(parted)                                                                  

Vous voyez bien que parted utilise la copie de secours de la table de partition, mais vous avez beau chercher dans la documentation, aucune commande ne permet de réécrire cette table! Heureusement, la solution est simple: il faut modifier la table de partition. Pour cela il suffit de créer une partition bidon, qui commence et qui finit au même bloc, le dernier, comme ceci:

(parted) mkpart                                                           
Partition name?  []? test
File system type?  [ext2]?                                                
Start? -1                                                                 
End? -1                                                                   

On vérifie le résultat:

(parted) print                                                               
Model: ATA ST3500630AS (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size     File system     Name     Flags
 1      1049kB  24,7GB  24,7GB   ext4            root
 2      24,7GB  25,8GB  1096MB   linux-swap(v1)
 5      24,7GB  500GB  1096MB    xfs
 3      500GB   500GB  49,2kB    ext2            test
 

Au passage, remarquez qu’il n’y a plus de message d’erreur… Maintenant supprimons la partition inutile ( attention, interdiction de se tromper! ):

(parted) rm 3                                                             
(parted) q                                                                
Information: You may need to update /etc/fstab.

Et voilà, sauvé!

Nasuni Corp. a publié le résultat de son rapport sur l’état du stockage Cloud, qui teste la vitesse de lecture, d’écriture et de suppression, la disponibilité et la montée en charge des trois grands acteurs du stockage Cloud public, à savoir Amazon, Google et Microsoft. Voici le lien vers le rapport complet.

Ce qui nous intéresse le plus dans ce rapport, ce sont certains chiffres de cette infographie (cliquez sur l’image pour l’infographie complète):

Que note-t-on? Les performances maximales des services de fichiers basés sur le Cloud public sont au moins 100 fois inférieures à un NAS professionnel tels les StorIQ d’Intellique. Les débits ne sont même pas équivalents à un disque USB grand public; les temps de réponses, eux, sont … très longs.

Pour un usage très modéré, strictement bureautique, cela pourra convenir à la rigueur (si on est prêt à travailler avec une performance très inférieure à celle du disque local de son PC); pour tout usage même modérément intensif, c’est encore clairement très insuffisant.

Le Cloud public reste donc une solution d’appoint, d’archivage ou de sauvegarde, mais certainement pas de production.

C’est un HGST He8. Il est rempli d’hélium comme son petit frère de 6 To.

Sa consommation électrique est très faible comparée au 6 To HDS “air”: 7,5W contre 11,5W en pointe. Il est également plus léger. Les tests de performance vont commencer, mais il est d’ores et déjà disponible.

---

Voilà une nouvelle rubrique, “les commandes utiles du jour”, pour tous ceux qui travaillent sous Linux avec des disques durs. Aujourd’hui, wipefs, lsblk et blkid.

Qui n’a pas eu à recycler un disque dur et voudrait savoir ce qu’il y a dedans avant de l’effacer? Qui n’a jamais voulu recycler un disque, mais ne pas être embêté par les messages d’erreur de LVM par exemple (qui va automatiquement verrouiller un disque comportant des signatures LVM)?

Les outils du jour vont nous aider:

• blkid : permet de savoir ce qu’il y a sur un disque, une partition.
• wipefs : permet de supprimer les signatures RAID, LVM, ou de systèmes de fichiers, ou encore les tables de partition sur un disque, une partition, ou un périphérique bloc quelconque (qui a dit disquette?)
  • lsblk : affiche une jolie arborescence des périphériques, bien pratique quand on a des disques découpés en partitions, elles-mêmes assemblées en RAID, le tout découpé en volumes logiques LVM!

Bien entendu il vous sera facile de trouver plus d’information dans les pages man de chacun de ces outils, qui font partie du paquet util-linux sous la plupart des distributions et sont généralement installés par défaut.

Bonus: file -s /dev/ : la commande file -s sur un périphérique bloc donne des informations recoupant celles fournies par blkid mais pas seulement. Utilisez les deux :)

---

Les SSD se sont généralisés bien sûr dans les ordinateurs portables, mais aussi dans le monde de l’entreprise où leur vitesse pure les rend indispensables aux applications transactionnelles, aux bases de données, etc. Afin de vous aider à faire le tri, voici donc une rapide présentation des technologies présentes dans les SSD.

Endurance des SSD

La mémoire flash ne permet qu’un nombre limité d’écritures par emplacement. Le nombre d’écritures possible dépend de la technologie flash utilisée, MLC ,eMLC ou SLC (voir ci-dessous).

DWPD ( diskful writes per day )

L’acronyme DWPD est un méthode d’évaluation de l’endurance des SSD qui évalue le nombre d’écritures complètes que supporte un SSD sur sa durée garantie d’utilisation (généralement 5 ans). Un SSD garanti 5 ans avec un DWPD de 10 peut donc être écrit entièrement 10 fois par jour pendant 5 ans.

MLC

La mémoire MLC (Multi Level Cell) stocke plusieurs bits par cellule, typiquement 2 (il existe des types de cellules stockant 3 ou 4 bits mais en général ils sont réservés aux clefs USB bas de gamme et autres stockages peu sollicités). C’est le type de mémoire flash le moins coûteux et le plus capacitif, mais sa durabilité est limitée à cent ou deux cent mille écritures environ.

eMLC

La mémoire eMLC (“enterprise MLC” ou “enhanced MLC”) est une variante de MLC un peu plus performante et fiable que le MLC (en général donnée pour 500 000 à 1 million d’écritures).

SLC

La mémoire SLC (Single Level Cell) ne stocke qu’un seul bit par cellule. Elle est donc environ deux fois moins dense que la MLC, mais en contrepartie est 10 fois plus durable (1 à 2 millions d’écritures). Le coût de la SLC est environ 3 à 4 fois supérieur au MLC à capacité équivalente.

déduplication

La plupart des contrôleurs SSD intègrent des fonctions de déduplication afin de limiter les écritures. Ceci a pour effet de fausser les mesures de performances lorsqu’on utilise soit un motif répétitif (sujet à une forte déduplication donc des performances anormalement élevées), soit au contraire un motif aléatoire (impossible à dédupliquer, donc donnant des performances anormalement basses).

Ramasse-miettes

Les mémoires flash s’écrivent par unités appelées pages d’une taille typiquement de 4 Ko, mais s’effacent par blocs typiquement de 128 ko à 2 Mo (ou plus). Afin d’améliorer la performance et de limiter l’usure de la flash, lors de la modification d’une page elle est en fait réallouée et récrite sur un emplacement libre, et la donnée antérieure marquée comme “périmée”. Un processus de “ramasse-miettes” peut être initié automatiquement ou volontairement pour effacer les blocs de données périmées et ainsi libérer de l’espace pour les prochaines écritures, de préférence à un moment où cette activité impactera le moins possible la production.

répartition de l’usure ( wear leveling )

Le contrôleur du SSD tient le compte du nombre de cycles d’effacement pour chaque bloc, de façon à répartir au mieux les données afin que tous les blocs aient un taux d’usure similaire. En effet, certains types de fichiers (fichier de pagination, base de données…) peuvent être modifiés très fréquemment toujours aux mêmes emplacements. Sans réallocation dynamique des blocs, les pages hébergeant ces fichiers atteindraient très rapidement leur limite d’usure entrainant la panne du SSD.

surallocation ( over provisioning )

Afin d’améliorer la fiabilité, chaque SSD comporte un surplus de mémoire flash non exploitable, utilisée pour répartir l’usure et prolonger le nombre total d’écritures possibles. La différence principale entre un SSD MLC et eMLC porte sur cette réserve: chez un même constructeur on trouvera généralement deux modèles comportant une capacité de mémoire flash physique équivalente (par exemple 512 Go de flash) mais la capacité disponible variera, de 400 Go pour la version eMLC à 460 ou 480 Go pour la version MLC.

Notons qu’il est parfaitement possible (et même recommandé) d’augmenter encore la durabilité d’un SSD en le partitionnant de manière à ne jamais utiliser une certaine proportion de son espace libre. Pour les applications intensives en écriture, nous conseillons de conserver 20% de la capacité inutilisée.

amplification des écritures ( write amplification )

Il peut arriver que le nombre d’écriture tel que reporté par le système d’exploitation donne lieu au niveau de la flash à un nombre d’écritures bien plus grand. Le cas le plus courant sera celui où le SSD étant utilisé près de sa capacité maximale, n’aura plus de blocs libres pour allouer de nouvelles pages et sera contraint d’effectuer des cycles de lecture/effacement/écriture de blocs entiers. Là encore, la solution consiste à conserver une bonne marge de capacité inutilisée sur le SSD.

protection de l’alimentation par condensateurs

Les SSD eMLC et SLC destiné aux usages professionnels comportent des condensateurs de forte capacité qui permettent, en cas de coupure intempestive de l’alimentation, de fournir suffisamment d’énergie pour terminer les écritures en cours et ainsi éviter une corruption de données.

PCIe vs SAS vs SATA

Les SSD sont disponibles sous différents formats (nous ne considérons pas les modules pour ordinateurs portables): SATA, SAS et PCIe.

• Les SSD à interface SATA sont les moins coûteux. Cependant, le SATA 3 ne permet qu’une vitesse de 6 Gbits/s, soit environ 700 Mo/s, ce qui est tout juste suffisant pour les modèles les plus performants.

• Les SSD à interface SAS 12 Gbits/s sont sensiblement plus coûteux, et sont généralement des modèles à base de SLC, beaucoup plus performants que les modèles SATA. On trouve des SSD SLC SAS pouvant fournir jusqu’à 120.000 IOPS (entrées-sorties par seconde) et plus.

• Les SSD à interface PCIe se présentent sous la forme de cartes PCIe. L’inconvénient de ce format est qu’il est impossible de remplacer un SSD défectueux sans interruption de service. Cependant l’interface PCI Express fournit une bande passante très élevée (plusieurs gigaoctets par seconde) et surtout des temps de réponse très faibles de l’ordre de 50 à 200 nanosecondes (contre 50 à 100 microsecondes pour le SAS). Les SSD sur PCIe présentent des performances de 100.000 à 10.000.000 d’IOPS environ.

C’est un HGST He6. Il est rempli d’hélium, du coup il est scellé (absence de vis) contrairement aux disques durs ordinaires.

Le premier test rapide indique une grande vitesse en accès séquentiel: 228 Mo/s en lecture, 183 Mo/s en écriture.

Sa consommation électrique est très faible comparée au 4 To “air”: 7,5W contre 11,5W en pointe. Il est également plus léger.

En terme de prix, il coûte environ 15% plus cher au To que le 4 To. Mais il faut considérer les gains en place, en consommation électrique, et en fiabilité. Bien qu’annoncé avec le même MTBF que le 4 To ( 2 millions d’heures), HGST est confiant sur sa capacité à faire mieux.

En fin d’année on devrait voir arriver le 6 To “air” et le 8 To “hélium”.

Administrateurs système, vous connaissez sans doute ces chiffres mystérieux qui apparaissent dans la sortie des commandes top, procinfo, uptime, w et tant d’autres, par exemple:

    [~]$ uptime 
     15:08:24 up 5 days,  4:17,  2 users,  load average: 0.08, 0.24, 0.29

Mais à quoi sert donc cette mystérieuse “load average”, charge système? Et pourquoi trois valeurs?

Une, cinq et quinze minutes

Les trois valeurs correspondent à la charge système moyenne sur les 1, 5 et 15 dernières minutes, telle que mesurée par le noyau. Notons au passage que les chiffres sont dans l’ordre inverse par rapport au temps… Si on veut déterminer la tendance, il faut donc considérer les chiffres à l’envers: dans l’exemple ci-dessus, la charge décroît au fil du temps, de droite à gauche.

Processeur, entrées-sorties, interruptions

Ceci ne nous dit pas ce qu’est la charge système. Elle est une mesure du nombre de processus actifs sur le système, et ajoute le nombre de processus en attente; l’unité 1.00 représente l’utilisation à 100% d’un processeur (ou coeur).

Du fait de cette double mesure, la charge système évolue en fonction à la fois de la charge du processeur, des entrées-sorties et des interruptions matérielles.

Si on ne considère que la charge processeur, un processeur utilisé à 100% pendant une minute se traduira par une charge de 1 pour la dernière minute (sous Linux; sous Solaris, la valeur est divisée par le nombre de processeurs ou coeurs); hors de toute autre activité, on aura donc une charge de 0.20 sur les 5 dernières minutes, et de 0.06 sur le dernier quart d’heure.

Charge et réactivité

Le lien entre la charge système et la réactivité du système est indirect: selon le type de système d’exploitation, une charge processeur maximale, produite par exemple par un calcul en arrière-plan, peut ne pas induire de ralentissement sensible pour les autres processus; a contrario, une charge système élevée induite par des processus nombreux en attente d’entrées-sorties (par exemple de très nombreux clients NFS accédant à de multiples fichiers) peut provoquer l’apparition de temps de réponses très importants.

Utiliser la charge

On considère généralement une valeur “élevée” si elle est très supérieure au nombre de processeurs; ce qui reste subjectif, une machine pouvant fonctionner normalement avec une charge système de 100 ou plus : la commande cat /dev/zero > /dev/null chargera un processeur à 100%, mais n’aura pas d’impact sur la réactivité parce qu’aucune ressource limitée n’est en jeu.

La charge système est un signal d’alarme; apprenez à connaître les plages de charge normale pour votre système, et recherchez les problèmes en cas de dérive importante.

Nous avons récemment effectué un test comparatif entre disques SATA-3 2 To de dernière génération et disques SAS 73 Go 15000t/mn de 2007. Pourquoi cela? afin d’évaluer la performance relative des disques haut de gamme d’il y a 5 ans avec les disques “classiques” actuels (que de nombreux constructeurs confinent à la catégorie “near line”).

La configuration matérielle et logicielle testée est en tout point identiques, seuls les disques ont été changés. La configuration testée est la suivante:

processeur	AMD Opteron 6128 8 coeurs
mémoire	16 Go DDR3 1333 ECC Kingston
carte mère	Supermicro H8SGL
contrôleur RAID	Adaptec 7805Q
configuration RAID	7 disques en RAID-6, bande de 256 Ko + 1 hot spare
Système d’exploitation	StorIQ 3.5.3 (base Debian 6.0.6)
Noyau	3.2.36-storiq64-opteron #1 SMP Thu Jan 3 19:10:41 CET 2013 x86_64 GNU/Linux

Les six tests suivants ont été effectués avec Bonnie++: écriture séquentielle de 32 Go, lecture et écriture simultanée de 32 Go, lecture de 32 Go; nombre positionnements aléatoires par seconde (“random seek”); nombre de créations de fichiers par seconde (divisé par 100 pour l’échelle); nombre de suppressions de fichiers par seconde (divisé par 100 pour l’échelle).

Voici les résultats chiffrés et le graphe:

Disques	Écriture Mo/s	écriture/lecture	Lecture Mo/s	pos./sec	100 créa./seconde	100 suppr./sec.
SAS 73 Go	424,43	209,35	531,71	893,70	281,12	385,30
SATA 2 To	655,35	306,75	713,13	627,05	325,76	386,21

On voit clairement que les disques SATA actuels font largement mieux que les disques SAS d’il y a 5 ans sur tous les tests sauf un, le positionnement aléatoire. Pensez-y lors du renouvellement de vos systèmes de stockage: un système SATA actuel peut venir remplacer un ancien système SAS dans la plupart des cas d’utilisation.

Afin d’optimiser les performances de votre serveur NAS StorIQ voici un petit guide d’optimisation des partages NFS.

Nombre de démons nfsd en attente

Le premier point à vérifier est le nombre de démons nfsd en attente de connexion défini dans le fichier /etc/defaults/nfs-kernel-server:

  # Number of servers to start up
  RPCNFSDCOUNT=8

. Dans l’idéal on aura à peu près autant de démons que de clients simultanés, de préférence dans une limite raisonnable autour de 4 démons par coeur de processeur (soit 16 à 64 en général).

Paramètres des ports

Le règle de base: si vous ne savez pas trop à quoi ça sert, n’y touchez pas. Les réglages par défaut sont bons: vous pourrez toujours saturer très aisément un lien gigabit ( environ 110 à 120 Mo/s utiles). Laissez donc les rsize, wsize tranquilles! La plupart des guides les mentionnant sur le net sont antédiluviens, et s’appliquent uniquement si vous avez un réseau 10 BaseT, et que votre serveur est une SparcStation 20.

Par contre, un problème classique se pose avec les systèmes BSD, donc Mac OS X: ils utilisent les ports réservés (inférieurs à 1024). Votre export doit donc avoir le paramètre “insecure” pour pouvoir fonctionner avec un Mac!

Paramètres des écritures

Oui, le mode synchrone est plus sûr. Cependant le risque d’utiliser le mode asynchrone reste raisonnable au vu de la fiabilité générale des systèmes actuels, et peut donner un gain significatif en performance. Particulièrement si on utilise un contrôleur RAID avec cache et batterie.

Paramétrage réseau

L’utilisation de “jumbo frame” ne fait plus guère de différence sur le matériel actuel sauf sur du réseau InfiniBand. Si vous utilisez du Gigabit Ethernet, il n’y a rien à gagner: vous devez aisément saturer un port à 110 ou 120 Mo/s en NFS3 comme en NFS4.

Par contre, l’utilisation du bonding est intéressante et souvent oubliée. Si vous voulez en savoir plus sur le bonding, je vous conseille la lecture de la page de manuel de l’outil StorIQ “bonding_cli”.

N’oubliez pas que quel que soit le mode d’agrégation des liens, une connexion IP transitera toujours par un seul câble physique. Si vous avez besoin de plus de débit entre deux machines seulement, le 10 Gigabit Ethernet s’impose, et n’est plus très cher.

Paramétrage des disques

La partie probablement la plus méconnue et la plus souvent oubliée. Il faut savoir que les réglages par défaut des systèmes linux sont curieusement optimisés plus pour des systèmes bureautiques que des serveurs, et ce alors qu’il y a sans doute plus de serveurs Linux que de postes clients.

Les différents éléments à passer en revue sont les suivants : l’ordonnanceur (IO scheduler), les files d’attente de disques, l’antélecture de disque.

Depuis quelques années l’ordonnanceur par défaut des systèmes Linux est “cfq” “Completely Fair Scheduler”. Il est plutôt efficace quand vous n’avez qu’un seul disque dur; par contre, si votre serveur utilise un contrôleur RAID matériel, celui-ci embarque son propre ordonnanceur qui sera toujours plus efficace car au fait de la configuration matérielle. Donc si vous utilisez un contrôleur RAID de quelque type que ce soit, configurez votre ordonnanceur comme “noop”. Il y a plusieurs manières de procéder dépendant des distributions; on peut le configurer lors de la compilation du noyau, sur la ligne de commande du chargeur de démarrage (GRUB ou LILO), ou en cours d’éxécution:

echo noop > /sys/block/sda/queue/scheduler

De même, la file d’attende disque par défaut convient pour un disque simple, mais pas du tout pour une grappe RAID doté d’un cache significatif. On peut également l’augmenter sensiblement. La valeur la plus adaptée dépend bien sûr du modèle de contrôleur, type de grappe RAID, etc:

echo 512 > /sys/block/sda/queue/nr_requests 

L’antélecture de disque (“readahead”) est également essentielle. La valeur par défaut du noyau Linux est probablement optimisée pour un disque IDE de 8 Go: 128 Ko. Il existe deux façons de le modifier, soit via la commande “blockdev”, soit comme précédemment via le pseudo-filesystem /sys:

echo 16384 > /sys/block/sda/queue/read_ahead_kb 

Là encore, il faudra expérimenter différentes valeurs pour obtenir la meilleure performance. Sur un serveur doté d’une grappe RAID assez grande, une valeur minimale se calcule en fonction de la largeur de bande de la grappe et du nombre de disques de données. Par exemple, une grappe RAID-6 de 12 disques comporte 10 disques de données et une largeur de bande de 64 Ko; la valeur minimale d’antélecture doit être 640 Ko. En pratique sur une machine rapide, on obtiendra une performance optimale en lecture séquentielle avec des valeurs beaucoup plus grandes (plusieurs mégaoctets).

Pour finir, le choix du système de fichier: la situation est heureusement assez simple. À mon sens, un seul système de fichier convient pour les volumes de grande taille, et c’est xfs.

Si vous partez d’une installation par défaut d’une distribution courante avec un volume partagé en ext3 et que vous appliquez tous ces conseils, vous pourrez aisément augmenter les performances de 100 à 500%.

Il est arrivé encore récemment qu’on me parle du RAID-5 comme si c’était toujours une technologie d’actualité. Du coup, je me sens obligé de faire un petit rappel à caractère sanitaire : le RAID-5 est mort depuis déjà quelques années, et n’est généralement pas le bon choix pour protéger ses données.

L’évolution de la capacité des disques durs est le principal facteur: la capacité des disques double globalement tous les 18 à 24 mois, alors que la vitesse augmente de quelques pourcents sur la même période. Résultat: le remplissage d’un disque dur prend de plus en plus de temps.

Premier problème: lorsqu’un disque tombe en panne, la grappe RAID reste non protégée de plus en plus longtemps, à savoir le temps nécessaire pour emplir un disque entier:

• en 1988, un disque de 40 Mo se remplissait en 2 à 3 minutes
• en 1998, un disque de 9 Go se remplissait en 15 à 20 minutes
• en 2008, un disque de 1 To se remplissait en 3 à 4 heures
• en 2010, un disque de 2 To se remplit en 5 à 6 heures
• En 2012, un disque de 4 To se remplit en 12 à 14 heures

Il s’agit là d’une performance maximale; il est normal que la performance réelle constatée soit beaucoup plus basse, surtout lorsque la grappe RAID est sollicitée pendant la reconstruction; il n’est pas anormal qu’une reconstruction se prolonge un ou deux jours, voire plus. Déjà, il faut avoir les nerfs solides, mais ce n’est pas le pire…

Ensuite les statistiques jouent contre nous : les disques durs courants présentent un taux d’erreur non correctible d’environ 1 bit pour 1E14 (mesuré par nous) à 1E15 (donné par les constructeurs). Ça paraît au premier abord beaucoup, mais en fait ça n’est pas tant que ça si on se rappelle que les disques durs actuels sont vraiment énormes et contiennent jusqu’à 3,2E13 bits (disque de 4 To). De plus, quand on additionne les disques dans une grappe RAID, on additionne les capacités mais aussi les erreurs.

Une grappe de 10 disques de 4 To contient environ 3,2E14 bits. Lors de la reconstruction d’un disque, on rencontrera (si le taux d’erreur réel est de 1 sur 1E14) 3,2 erreurs de façon statistiquement certaine. Alors bien sûr, 3 erreurs de 1 bit ce n’est pas grand chose (même si c’est déjà une corruption, donc une perte de donnée) mais n’oubliez pas que vous avez aussi 10% de chances de rencontrer 32 erreurs, et 1 pour cent de chance d’en rencontrer 320!

À partir de quel moment le niveau de corruption devient-il inacceptable? À partir de quel moment l’intégrité du système de fichier dans son ensemble est-elle en jeu? Voulez vous essayer? Êtes-vous prêt à risquer 20, 30 To de données?

Voilà pourquoi depuis que les disques de 1 To et plus se sont généralisés, on considère que le RAID-5 présente un risque inacceptable. Le RAID-6 (avec deux parités) constitue la seule manière raisonnable d’agréger des disques de forte capacité.

Les seuls cas où le RAID-5 doit être envisagé sont pour des disques de petite capacité comme les disques SAS de 300 Go, ou pour des disques présentant à la fois une capacité limitée et un taux d’erreur réduit en lecture, les SSD.

Et si on vous propose de stocker vos données sur des grappes de disques SATA 2, 3 ou 4 To en RAID-5, soyez raisonnable: fuyez!

Les disques SSD sont bien plus rapides que les disques magnétiques, mais chers et de capacité limitée. Les disques magnétiques SATA ont de fortes capacités, mais des performances limitées. Mais aujourd’hui on peut avoir fromage et dessert grâce au RAID hybride!

Le système consiste en un RAID-10 mêlant disques SSD et disques magnétiques de forte capacité. La configuration testée est un ST2R doté de 4 SSD 64 Go SATA et de 4 disques 7200t/mn de 3 To.

On obtient deux grappes RAID, une de 256 Gigaoctets ultra-rapide (pour les applications transactionnelles) et une de plus de 8 Téraoctets moins performante ( plus de 400 Mo/s tout de même).

En comparant avec les tests des SSD de l’année dernière, on voit qu’on obtient avec quatre SSD des performances en lecture très proches de celles obtenues avec huit SSD l’an dernier! Sachant que ce sont exactement les mêmes qui ont été utilisé pour les deux tests… On a donc le meilleur du SATA et du SSD: une grosse performance ET une grosse capacité.

IT Channel nous fait part d’une étude iSuppli sur l’évolution à venir des stockages magnétiques. Plein de bonne volonté, le rédacteur mélange joyeusement les gigabits et les giga-octets ( 1 Go = 8Gb ) mais l’erreur est si commune qu’on la lui pardonne.

Cette étude ne déroge pas aux règles du genre et annonce des chiffres impressionnants ( augmentation de 180019%! toujours plus pour moins cher! ). Mais pour qui sait lire entre les lignes, cette communication de Seagate (qui vaut je suppose, pour les autres, pardon, l’autre constructeur de disques durs) dévoile plus que cela: une inflexion à la baisse de l’augmentation des capacités, qui d’exponentielle de 1980 à 2005, semble de plus en plus prête à atteindre un plateau.

Un petit dessin disant plus qu’un long discours, voyons les projections, en échelle logarithmique et en échelle linéaire (cliquez sur les images pour agrandir).

La projection naïve correspond à la tendance des années 80-90, un doublement de la capacité tous les 18 mois. On constate aisément que cette projection ne correspond plus à la réalité depuis plusieurs années.

La projection corrigée prolonge simplement la tendance des années récentes (2005 à 2012). La courbe reste exponentielle, mais s’infléchit sensiblement (c’est très clair sur l’échelle linéaire).

Mais la projection des valeurs indiquées par iSuppli raconte une histoire toute différente: une nouvelle inflexion vers le bas de la tendance dans les prochaines années! Sur l’échelle logarithmique (chaque graduation valant 10 fois la précédente) c’est très clair: on quitte la tendance exponentielle pour s’approcher du plateau.

Autrement dit: la croissance de la taille des disques va encore ralentir dans les prochaines années. Ce n’est guère étonnant: les constructeurs ont en effet tiré les leçons de la crise de production liée aux inondations en Thaïlande; ils ont réduits les volumes, mais maintenu le chiffre d’affaire tout en augmentant les marges! Peut-être que la formation d’un oligopole planétaire (puisque Western Digital et Seagate totalisent désormais plus de 90% de la production mondiale de disques durs) n’y est pas non plus totalement étrangère.

Conclusion: la communication d’iSuppli nous dévoile le contraire de ce qu’elle semble dire au premier abord, à savoir que les capacités des disques croîtront de moins en moins vite dans les prochaines années.

Premièrement, l’option -e sur la ligne de commande est suivie d’une chaîne de perl à exécuter immédiatement. Selon l’OS, on préferera mettre le code entre simple ou double guillemets. Un exemple:

perl -e 'print qq/Hello world!\n/;'

Notez l’usage de qq// au lieu de ” (simples guillemets). Étant donné que la chaîne de code est entourée de guillemets simples, ceci évite soit des problèmes avec le shell, soit d’échapper systématiquement les guillemets à l’intérieur du code. Si on utilise les guillemets doubles, attention au shell! Il risque d’interpréter les variables. Le point suivant est l’option -n. -n ouvre chaque fichier passé sur la ligne de commande et en passe chaque ligne au code perl (via $_). Voici un exemple:

perl -n -e 'print qq/$.:\t$_\n/;' textfile.txt

l’exemple précédent parcourt chaque ligne du fichier ‘textfile.txt’ et affiche cette ligne précédée de son numéro de ligne ( c’est ce que contient la varibable spéciale $.). On peut considérer que l’option -n est équivalente à

while( <> ) { ........ }.

Comme une grande partie des unelignes doivent afficher le contenu modifié des fichiers traités, nous pouvons économiser nos petits doigts grâce à l’option -p en lieu et place de -n. L’effet est le même, mais -p rajoute un print $_ implicite à chaque itération de la boucle. Quelque chose comme ça:

while ( <> ) {
    .......... # Votre code ici.
    print $_;
}

Ceci est intéressant pour spécifier une action qui modifie $_ à chaque itération pour afficher le résultat modifié pour chaque ligne. Voici un exemple:

perl -p 's/\bperl\b/Perl/g;' textfile.txt

Ce code va parcourir “textfile.txt” et remplacer toutes les occurences de ‘perl’ par ‘Perl’. Le résultat est envoyé vers STDOUT, à moins que vous ne le redirigiez… Envoyons le vers un autre fichier:

perl -p 's/\bperl\b/Perl/g;' textfile.txt >temptext.txt

Facile, n’est ce pas? Maintenant, mieux. Souvent on voudrait simplement modifier le fichier “sur place”. L’option -i fait exactement cela. Avec l’option -i, on peut soit utiliser -i, ou préciser -i.bak pour indiquer à Perl de créer une copie de sauvegarde du fichier avant de le modifier. L’extension donnée sera ajoutée au nom dufichier; ‘.bak’, ‘.old’, ‘.proutprout’ ou ce que vous voudrez. Voilà comment utiliser l’édition en place:

perl -pi.bak -e 's/\bperl\b/Perl/g' infile.txt

Ce code va parcourir “textfile.txt” et remplacer toutes les occurences de ‘perl’ par ‘Perl’, puis va enregistrer le résultat dans le fichier. Une copie du fichier d’origine sera sauvegardée sous le nom ‘infile.txt.bak’.

Une autre option intéressante est -M. -M équivaut à use ….. par exemple “-MData::Dumper -e “print Dumper \%::” aura le même effet que d’utiliser

use Data::Dumper

dans le bloc de code.

Voilà, nous avons vu les options les plus courantes, on peut déjà en faire beaucoup! La prochaine fois, nous verrons quelques autres options utiles. Et aussi le “baiser eskimo”. Ah ah, je vois les petits curieux…

---

. * référence évidemment aux fameux “deulignes” de l’immensément regretté HHHHHHHHHebdo (que les moins de 20 ans ne peuvent pas connaître, les pôvres).

Les nouveaux SSD basés sur les contrôleurs SanForce de la famille 1200 présentent une caractéristique intéressante : la déduplication au niveau bloc intégrée dans le contrôleur, une technologie nommée “DuraWrite” par le fabricant.

Pour bien comprendre les avantages de cette nouvelle fonctionnalité, il convient de rappeler comment fonctionnent les SSDs : un tel “disque” peut écrire par “page” de 4Kio, mais doit effacer par bloc de 128 Kio au minimum; par ailleurs un bloc ne peut être écrit et effacé qu’un nombre limité de fois ( pour plus de détails, voir l’article précédent Les promesses du SSD).

La déduplication de bloc signifie qu’avant chaque écriture, le contrôleur vérifie si un bloc identique n’est pas déjà stocké, auquel cas une nouvelle écriture (et potentiellement, un effacement) est évitée. Du coup, la durée de vie est augmentée proportionellement aux écritures évitées; et la performance augmente dans le même rapport, puiqu’on économise sur les opérations les plus coûteuses, l’écriture et surtout l’effacement.

MLC et SLC

Un petit rappel : il existe deux grandes familles de SSD que l’on identifie par l’organisation de la mémoire flash: les MLC et les SLC. Les MLC stockent deux bits par cellule flash, les SLC 1 seul. Le corollaire est qu’à quantité de mémoire égale, un MLC présente le double de capacité. Par contre le SLC est supposé bien plus rapide en écriture, et surtout bien plus durable : les cellules MLC étaient en 2009 données pour capables de 10 000 écritures, contre 100 000 aux SLC.

Cependant les choses évoluent, et les générations actuelles de puces flash MLC sont généralement données pour capables de 100 000 écritures, et 1 000 000 pour les SLC. Autrement dit, les MLC actuelles ont la même durée de vie que les SLC d’il y a deux ans! Voici un premier point.

Second point, quel gain réel nous apporte les nouveaux disques MLC à contrôleur SF1200? Question à laquelle nous nous sommes empressés de répondre par une série de tests.

Le test

Configuration testée :

• carte-mère Supermicro H8DIi
• 2 processeurs AMD 2376
• 16 Go de RAM DDR2 400Mhz ECC Kingston
• contrôleur RAID Adaptec 5805
• SSD SLC : 8 SuperTalent UltraDrive GX 64 Go (modèle 2010)
• SSD MLC : 8 SuperTalent TeraDrive CT 60 Go (modèle 2011)

Les 8 SSD ont été agrégés en une grappe RAID-10 d’une largeur de bande de 16 Ko. Nous avons ensuite effectué une série de 16 tests avec Bonnie++.

Tout d’abord, le test d’accès séquentiel : écriture, lecture et écriture simultanées, lecture :

Les SSD MLC sont en fait nettement plus performants que les SLC de l’année dernière : 590 Mo/s en écriture contre 200 Mo/s; 1150 Mo/s en lecture contre 600 Mo/s!

Ensuite, le test de création, accès et suppression de fichiers, séquentiel puis aléatoire, en augmentant le nombre de fichiers pour le test à 80 000:

L’écart est assez peu significatif. Il faut dire que le contrôleur RAID lui-même est probablement assez proche de sa performance crête autour de 45 000 IOPS. Cependant le MLC est encore nettement gagnant.

Pour le test simulant des accès de base de données (accès aléatoires de 8 Ko) les SSD MLC ont également été testés en RAID-6 (bande 64 Ko), RAID-5 (bande 16 Ko), RAID-10 (bande de 256 Ko). L’accès en écriture seule a également été testé. En abscisse, nous avons le nombre d’accès parallèles (threads), en ordonnée le nombre d’opérations par seconde:

On constate là encore une forte supériorité du MLC, qui sature les capacités du contrôleur. Il n’y a pas d’écart important entre le RAID-5 et le RAID-6, et le RAID-10 n’apporte pas plus de 10% de gain. On peut raisonnablement envisager de faire des économies et d’utiliser ces SSD en RAID-5 ou RAID-6 sans arrière-pensée, même (sacrilège!) pour de la base de données.

On remarque que la performance en écriture aléatoire est nettement inférieure à la lecture, ce qui est attendu. On relativisera cependant en pensant que pour obtenir cette performance ( 14 700 IOPS, 47 Mo/s) en accès aléatoire avec des disques “en métal rouillé” il faut environ 60 disques SAS 15000 tours/minute, et 120 disques SATA 7200 tours/minute.

Some people wanted some more information on the test setup used in the deduplication benchmarks, so here are some more details :

• dual Opteron 2376 system
• 16 GB RAM
• 2 Adaptec 52445 RAID controllers
• 24 Hitachi Ultrastar 2 TB drives in 2 RAID-6 arrays, 64KB stripe.
• Kernel Linux 2.6.32.11 AMD64 (custom built from vanilla www.kernel.org source)
• RAID arrays agreggated with LVM and mounted as an XFS filesystem.
• Lessfs 1.1.9.10

Here are the bonnie++ results (meaningless and empty columns removed). You can clearly see the very low LessFS metadata performance (though Lessfs 1.2.x improves on this, more benchmarks to come).

name	put_block	rewrite	get_block	seeks	ran_del
XFS	864107	393836	1048367	555,5	28255
XFS	885654	392354	1076189	556,3	25665
XFS	812471	395010	1109478	563,5	28611
XFS	826676	389504	974248	573,7	28056
lessfs	114409	53563	218081	3090,8	24
lessfs	127666	71852	225472	3165,6	23
lessfs	124484	73638	216317	1720,4	23
lessfs	124739	73279	224726	2427,5	23

The block performance results are drawn below :

As you can see, deduplicated performance is more than enough to saturate a 1 Gb network. For more performance hungry users, it will be a great secondary storage. Notice that it’s possible to both have your cake and eat it as you might use both XFS — for maximum performance — and Lessfs — for maximum capacity — storage simultaneously.

Happy New Year!

I tested various real-time online deduplication implementations at the filesystem level under Linux, namely Opendedup, Lessfs and a couple of proprietary ones. What’s great of course is that it’s transparent, you can share data using all protocols at once (NFS, CIFS, iSCSI, FTP, whatever), namely you can use your dedupe filesystem exactly like an ordinary one.

The only concern can be about performance and particularly IOPS; Some systems get decent throughput but in any case the IOs are all basically turned into random IOs, therefore dedupe hurts performance badly any way you turn it.

Some will ask : why are all IOs made random? Because while you’re sending data to the “deduplicator”, it checksums blocks of data as they’re coming and compares them against its hash index of blocks, throwing away any block previously seen. If the filesystem is big, this database won’t fit in memory and will be continuously scanned while writing so the disk access pattern is basically write a bit sequentially, read the index, write some more data, read the index…

Reading is a different matter; we suppose that about half the data is not unique, so when you’re reading some sequential data, you’re actually reading blocks written at different times and as such physically scattered around the disks. So reading is almost certainly quasi random, limiting seriously performance.

Example from real benchmarks : I created 60 TB of semi-randomized data, occupying a total of 19 TB after combined compression/dedupe. The filesystem performance without dedupe is about 350 MB/s write, 500 MB/s read, 1500 IOPS. With dedupe the figures are 120 MB/s write (but it varies extremely from 30 MB/s to 300 at times) and 200 MB/s read; however IOPS drop to an abysmal 40 to 50.

My conclusion is that it’s not generally commendable as a primary storage application; however as a “warm” archive or backup, or for rarely accessed files, it’s wonderfully effective.

D’après The rise of Worse is Better.

À peu près tous les concepteurs de Common LISP et CLOS, dont moi-même, ont été extrêmement exposés au style de conception du MIT/Stanford. L’essence de ce style peut être rendue par la phrase : “ce qu’il faut”. Pour un tel concepteur, il est important de réussir à obtenir ces caractéristiques:

• simplicité - la conception doit être simple, en implémentation comme en interface. Il est plus important pour l’interface d’être simple que pour l’implémentation.
• exactitude. La conception doit être correcte dans tous les aspects observables. L’inexactitude n’est simplement pas autorisée.
• Cohérence. Le modèle ne doit pas être incohérent. La conception peut être légèrement moins simple et moins complète pour éviter les incohérences. La cohérence est aussi importante que l’exactitude.
• Complétude. La conception doit gérer autant de situations importantes que possible. Tous les cas raisonnablement envisageables doivent être couverts. La simplicité n’est pas autorisée aux dépens de la complétude.

Je pense que la plupart des gens admettront que ce sont de bonnes caractéristiques. J’appellerai l’usage de cette philosophie dans la conception “l’approche MIT”. Common LISP (y compris CLOS) et Scheme représentent l’approche MIT dans la conception et l’implémentation.

La philosophie “moins bien, c’est mieux” diffère subtilement:

• simplicité. la conception doit être simple, en implémentation comme en interface. Il est plus important pour l’implémentation d’être simple que pour l’interface. La simplicité est la plus importante considération dans un concept.
• Exactitude. La conception doit être correcte dans tous les aspects observables. Il est plus important d’être simple que correct.
• Cohérence. La conception ne doit pas être incorrecte de manière trop évidente. La cohérence peut être sacrifiée à la simplicité dans certains cas, mais il est préférable d’abandonner les parties qui concernent les circonstances moins courantes que d’introduire soit plus de complexité dans l’implémentation, soit des incohérences.
• Complétude. La conception doit gérer autant de situations importantes que possible. Tous les cas raisonnablement envisageables devraient être couverts. La complétude peut être sacrifié au profit de toute autre qualité. En fait, la complétude doit être sacrifiée quand la simplicité d’implémentation est en jeu. La cohérence peut être sacrifié pour atteindre la complétude si cela permet de maintenir la simplicité; la cohérence de l’interface n’a pas de valeur particulière.

Les anciennes versions d’Unix et de C sont des exemples de cette école de conception, et j’appellerai cette stratégie “l’approche New Jersey”. J’ai intentionnellement caricaturé la philosophie du “moins bien, c’est mieux” pour vous convaincre que c’est de toute évidence une mauvaise philosophie et que l’approche New jersey est une mauvaise approche.

Cependant, je crois que le “moins bien, c’est mieux”, même présenté comme un épouvantail, a de meilleures capacités de survie que “ce qu’il faut”, et que l’approche New Jersey appliquée au logiciel est supérieure à l’approche MIT.

Permettez moi de répéter une histoire qui montre la validité de la distinction entre MIT et New Jersey, et que les promoteur de chacune de ces philosophies pensent réellement que leur philosophie est la meilleure.

Deux fameux personnages, l’un du MIT et l’autre de Berkeley (mais travaillant sur Unix) se rencontraient pour discuter de problèmes de systèmes d’exploitation. La personne du MIT connaissait bien ITS (le système d’exploitation du labo d’intelligence artificielle du MIT) et avait lu les sources d’Unix. Il voulait savoir comment Unix résolvait le problème du contrôle de processus “loser”. Ce problème apparaît lorsqu’un programme utilisateur invoque une routine système pour effectuer une opération de longue durée qui peut avoir un état significatif, comme des tampons d’entrée-sortie. Si une interruption se produit pendant cette opération, l’état du programme utilisateur doit être sauvegardé. Comme l’invocation de la routine système est généralement une seule instruction, le contrôle de processus du programme ne peut capturer de manière adéquate l’état du processus. La routine système doit donc soit ressortir, soit continuer sur sa lancée. “Ce qu’il faut” est ressortir, restaurer le programme utilisateur à l’instruction précise qui a invoqué la routine système afin qu’à la reprise du programme utilisateur après l’interruption, par exemple, on rentre à nouveau dans la routine système. On appelle cela contrôle de processus “loser” parce que le contrôle de processus est forcé en mode “loser”, “loser” étant le petit nom pour “utilisateur” au MIT.

Le gars du MIT ne voyait aucun code pour prendre soin de ce cas et demanda au gars du New Jersey comment le problème était pris en charge. Le gars du New Jersey répondit que les gens d’Unix étaient conscients du problème, mais que la solution était pour la routine système de toujours finir, mais parfois un code d’erreur serait retourné pour signaler que la routine avait échoué à terminer son action. Un programme utilisateur correct, donc, devait vérifier le code d’erreur pour déterminer s’il devait simplement essayer d’appeler la routine système à nouveau. Le gars du MIT n’aimait pas cette solution parce que ce n’était pas “ce qu’il faut”.

Le gars du New jersey dit que la solution Unix était correcte, parce que la philosophie de conception d’Unix était la simplicité et que “ce qu’il faut” serait trop complexe. Par ailleurs, les programmeurs pouvaient facilement ajouter ce test et cette boucle supplémentaires. Le gars du MIT remarque que l’implémentation était simple mais que l’interface de la fonctionnalité était complexe. Le gars du New Jersey fit alors que le bon compromis avait été choisi dans Unix, à savoir la simplicité d’implémentation était plus importante que la simplicité de l’interface.

Le gars du MIT marmonna alors que parfois il faut être un vrai dur pour faire un poulet bien tendre, mais le gars du New Jersey n’a pas compris (je ne suis pas sûr d’avoir compris non plus).

Maintenant je veux arguer le fait que “moins bien c’est mieux” est mieux. C est un langage de programmation conçu pour écrire Unix, et il a été conçu en suivant l’approche New Jersey. C est par conséquent un langage pour lequel il est facile d’écrire un compilateur acceptable, et il impose au programmeur d’écrire du texte facile à interpréter par le compilateur. Certains ont dit que le C était un langage assembleur sophistiqué. À la fois les anciens Unix et compilateurs C avaient des structures simples, étaient facile à porter, demandaient peu de ressources machine pour s’exécuter, et fournissaient à peu près 50 à 80 % de ce que l’on attend d’un système d’exploitation et d’un langage de programmation.

La moitié des ordinateurs existant à un instant quelconque sont inférieurs à la moyenne (plus petits, plus lents). Unix et C fonctionnent bien sur ceux-ci. L’approche “moins bien, c’est mieux” signifie que la simplicité d’implémentation a la plus haute priorité, ce qui veut dire qu’Unix et C sont faciles à porter sur de telles machines. Par conséquent, puisque les 50% de fonctionnalité fournies par C et Unix sont satisfaisants, on s’attend à ce qu’ils commencent à apparaître partout. Et c’est bien ce qu’il s’est passé, n’est ce pas?

Unix et C sont les virus informatiques ultimes.

Un bénéfice supplémentaire de l’approche “moins bien, c’est mieux” est que le programmeur est conditionné à sacrifier de la sûreté, de la commodité et des ennuis pour obtenir une bonne performance et une utilisation modeste de ressources. Les programmes écrits en utilisant l’approche New Jersey fonctionneront bien sur de petites machines comme sur des grosses, et le code sera portable puisqu’il est écrit par dessus un virus.

Il est important de se rappeler que le virus initial doit être globalement bon. Dans ce cas, la propagation virale est assurée aussi longtemps qu’il reste portable. Une fois que le virus s’est répandu, on fera pression pour l’améliorer, peut-être en augmentant la fonctionnalité plus près de 90%, mais les utilisateurs ont déjà été habitué à accepter quelque chose d’inférieur à “ce qu’il faut”. En conséquence, le logiciel “moins bien c’est mieux” premièrement commencera à être accepté, deuxièmement habituera les utilisateurs à en attendre moins, et troisièmement sera amélioré jusqu’au point où il sera presque comme il faut. En terme concrets, bien que les compilateurs Lisp en 1987 aient été à peu près aussi bons que les compilateurs C, il y a nettement plus d’experts en compilateurs qui veulent améliorer les compilateurs C que les compilateurs Lisp.

La bonne nouvelle c’est qu’en 1995 nous auront un bon système d’exploitation et un bon langage de programmation; la mauvaise nouvelle c’est que ce seront Unix et C++.

Il y a un dernier avantage à “moins bien c’est mieux”: Comme le système et le langage du New Jersey ne sont pas vraiment assez puissants pour construire de grands et complexes logiciels monolithiques, les grands systèmes doivent être conçu pour réutiliser des composants. Par conséquent une tradition d’intégration fleurit.

Comment “ce qu’il faut” se défend-il? Il y a deux scénarios de base : le scénario du “grand système complexe” et celui du “pur joyau”.

Le scénario du “grand système complexe” se déroule ainsi:

Tout d’abord, le système “qu’il faut” doit être conçu. Ensuite l’implémentation doit en être conçue. Enfin il est implémenté. Comme c’est “ce qu’il faut”, il a pratiquement 100% de la fonctionnalité souhaitée, et la simplicité d’implémentation n’ayant pas été une préoccupation cela a pris très longtemps. Le système est vaste et complexe. Il nécessite des outils complexes pour l’utiliser correctement. Les derniers 20% prennent 80% de l’effort, et de fait “ce qu’il faut” prend du temps, et ne fonctionne correctement que sur le matériel le plus sophistiqué.

Le scénario du “pur joyau” se déroule ainsi:

La conception de “ce qu’il faut” demande une éternité, mais le système est plutôt compact. L’implémenter de façon à ce qu’il soit rapide est soit impossible, soit au-delà des capacités de la plupart des développeurs.

Ces deux scénarios correspondent à Common Lisp et Scheme.

Le premier scénario est aussi celui des logiciels d’intelligence artificielle classique.

“Ce qu’il faut” est fréquemment un logiciel monolithique, mais sans raison autre que sa conception est menée ainsi. De fait cette caractéristique est accidentelle.

La leçon à retenir de tout ceci est qu’il est souvent indésirable de commencer par “ce qu’il faut”. Il est préférable d’avoir la moitié de “ce qu’il faut” disponible afin qu’il se répande comme un virus. Une fois que les gens s’y sont attachés, prenez le temps de l’améliorer jusqu’à 90% de “ce qu’il faut”.

La leçon à ne surtout pas retenir serait de prendre cette parabole littéralement et d’en conclure que C est le bon véhicule pour l’intelligence artificielle. La solution à 50% doit être à peu près juste, et dans ce cas elle ne l’est pas.

Mais on peut aussi conclure que la communauté Lisp doit sérieusement reconsidérer sa position sur la conception en Lisp. J’en dirai plus sur ce sujet ultérieurement.

rpg@lucid.com

Un jour, maître Foo dit à un programmeur en visite: “Il y a plus de la nature d’Unix dans une ligne de script shell que dans dix mille lignes de C”.

Le programmeur, qui était très fier de sa maîtrise du C, dit :”Comment est-ce possible? C est le langage dans lequel est écrit le noyau même d’Unix!”.

Maître Foo repondit: “Cela est vrai. Néanmoins, il y a plus de la nature d’Unix dans une ligne de script shell que dans dix mille lignes de C”.

La détresse gagnait le programmeur : “Mais à travers le langage C nous expérimentons l’illumination du Patriarche Ritchie! Nous ne faisons plus qu’un avec le système d’exploitation et la machine, atteignant des performances sans égales!”

Maître Foo repondit: “Tout ce que tu dis est vrai. Mais il y a plus de la nature d’Unix dans une ligne de script shell que dans dix mille lignes de C”.

Le programmeur fit une grimace et se leva pour partir. Mais Maître Foo fit un signe de tête vers son étudiant Nubi, qui écrivit une ligne de script shell sur le tableau blanc tout proche et dit : “Maître programmeur, considérez ce tube (“pipe”). Implémenté en C, ne ferait-il pas près de dix mille lignes?”

Le programmeur marmonna dans sa barbe, en contemplant ce qu’avait écrit Nubi. Finalement, il admit qu’il en était ainsi.

“Et combien d’heures vous faudrait-il pour écrire et déboguer ce programme C?” demanda Nubi.

“Beaucoup.” admit le visiteur. “Mais seul un imbécile y passerait son temps alors que l’attendent de nombreuses tâches plus importantes.”

“Et qui comprend mieux la nature d’Unix?” demanda Maître Foo. “Celui qui écrit dix mille lignes, ou celui qui percevant la vacuité de la tâche, gagne en mérite en ne codant pas?”

Entendant cela, le programmeur fut illuminé.

d’après Rootless Root, the Unix koans of Master Foo.

Suite à l’embauche de l’ex patron d’HP Mark Hurd par Oracle, HP attaque son ex-employé en justice. Le moins que l’on puisse dire est que Larry Ellison n’a pas l’air content, si on en croit le communiqué de presse d’Oracle. En voici une traduction rapide :

“Oracle a longtemps considéré HP comme un partenaire important”, a déclaré Larry Ellison, CEO d’Oracle. “En émettant cette attaque en justice vindicative contre Oracle et Mark Hurd, le conseil d’administration d’HP agit avec un mépris complet de ce partenariat, de nos clients communs, de leurs actionnaires et employés. Le conseil d’administration d’HP rend virtuellement impossible pour Oracle et HP de continuer à coopérer et travailler ensemble sur le marché informatique (souligné par nous).

On peut affirmer sans trop s’avancer qu’il va y avoir du sport.

d’après Seven levels of Perl Mastery

• Novice
• Initié
• Utilisateur
• Expert
• Hacker
• Gourou

Magicien

• Tutoie la femme de Larry.
• A écrit ou récrit des parties majeures du compilateur ou de l’interpréteur Perl.
• Pense récrire le moteur d’expressions régulières, l’allocateur de mémoire ou le ramasse-miettes.
• N’écrit pas de jeux en Perl, parce qu’il a réalisé que Perl lui-même est un jeu.

d’après Seven levels of Perl Mastery

• Novice
• Initié
• Utilisateur
• Expert
• Hacker

Gourou

• Peut répondre à toute question sur Perl instantanément.
• Peut tout écrire en Perl - et le fait.
• Exploite des fonctionnalités non documentées du langage.
• Écrit du code qui étonne même Larry.
• Implémente des objets opaques et des regexps compilées en utilisant les “clôtures”.
• Peut lire et comprendre la sortie du compilateur perl en C.
• Embarque des interpréteurs Perl dans de grosses applications.
• A écrit son propre module de débogage -d:.
• A utilisé la programmation orientée-objet avant même qu’elle existe.
• Discute avec le Pumpking de prendre son tour (encore).

d’après Seven levels of Perl Mastery

• Novice
• Initié
• Utilisateur
• Expert

Hacker

• Écrit des jeux en Perl.
• A écrit des modules d’extension en C.
• Utilise AUTOLOAD et les clôtures de façon originale.
• Apprécie en esthète la “Schwartzian transform”.
• Se régale de la flexibilité du système d’objets de Perl.
• A écrit son propre traducteur pod vers X.
• Comprend la sortie de Perl -D.
• Accède directement à la table des symbôles Perl.
• Soumets des rapports de bogues avec des patchs fonctionnels.
• Édite des fichiers en utilisant une version spéciale de vi ou emacs embarquant Perl.
• A écrit des modules, des pages de manuel et des outils de la distribution standard de Perl.

d’après Seven levels of Perl Mastery

• Novice
• Initié
• Utilisateur

Expert

• Écrit des JAPHs pout impressioner ses amis et embêter ses collègues.
• Commence tous ses programmes par use strict.
• Pense que Perl doit seulement être Perl.
• A suffisemment utilisé les contextes implicites à son avantage pour ennuyer d’autres gens.
• Sait comment créer des enregistrements et des objets avec des hashrefs.
• Utilise syscall pour atteindre un appel système non documenté.
• Maudit la flexibilité du système d’objets de Perl.
• utilise /e dans les substitutions.
• A commencé à se demander à quoi peuvent bien servir les typeglobs.
• A écrit ses propres modules en Perl.
• Commence à envisager toutes les données en termes d’expressions régulières.
• Comprend pourquoi les regexps ne peuvent pas analyser des données imbriquées.
• Récrit des petits utilitaires en Perl.