EEE PC d'ASUS - Page 19

squalyl (./536) :
very> tu te fous de la geule du monde, j'ai même pas envie de rentrer dans ton faux troll (ou plutot ta vraie incompétence, que t'acceptes même pas de reconnaitre).

Je t'assure que je connais 'monolithique' comme un mot français ( Formé d'un seul bloc. ), que je l'utilise en français, et que je ne connaissais pas l'usage spécifique dans le monde des noyaux..

Bon j'ai jamais dit que j'étais un spécialiste des noyaux hein. (mais j'appelle pas ça de l'incompétence, je n'ai pas à être compétent dedans, c'est juste de la non-connaissance .. )

Sa fait plaisir de se faire limite insulter quand on discute gentillement et honnêtement..

en même temps je sais pas si c'est très utile. si?

Thibaut (./538) :

CRC ou mieux, couche physique ou pas, ça change quoi ? Ca ne change pas le fait qu'il y a déjà un contrôle d'erreurs et qu'un checksum n'apportera rien. Le contrôle d'erreur que j'appelle "physique" détecte déjà les corruptions nan ?
Et j'ose espérer qu'il y en a sur les disques durs... Il faudrait vérifier.

Ca change rien pour les CD ; et ça existe pour les disques, mais force est de constater que ça ne suffit pas (d'autant que le disque au niveau physique ne peut pas savoir quelles sont les informations capitales à consolider).

very> alors désolé, je modère mes propos.

Nil> sur un CD on utilise 10 bits pour coder chaque octet je crois. C'est mieux qu'un CRC qui peut corriger qu'un nb restreint de bits dans un bloc.

Thibaut (./538) :
CRC ou mieux, couche physique ou pas, ça change quoi ? Ca ne change pas le fait qu'il y a déjà un contrôle d'erreurs et qu'un checksum n'apportera rien. Le contrôle d'erreur que j'appelle "physique" détecte déjà les corruptions nan ?

Et j'ose espérer qu'il y en a sur les disques durs... Il faudrait vérifier.

Bah à ma connaissance, il n'y a pas d'équivalent sur les disques durs... Et en fait, si ça ne servait vraiment à rien, ça m'étonnerait fort que les gars de Sun ne soient pas au courant

En tout cas, je me suis déjà retrouvé avec des archives corrompues alors qu'elles n'avaient pas bougé de disque... et si j'avais eu un FS avec CRC, je m'en serais rendu compte plus rapidement
(et la journalisation n'a aucun rapport avec l'intégrité des données)

Martial Demolins (./546) :

Flanker (./522) :
et la fiabilité des supports, non, même actuellement tu peux avoir des fichiers corrompus... et après, si c'est un fichier que tu ne regardes pas souvent, tu ne sauras pas quand il a été corrompu :/

Faut pas exagérer... il me semble avoir eu 1 et un seul fichier corrompu depuis 10 ans que j'ai un PC... et encore, j'avais réussi à le récupérer ^^

ça m'est arrivé plus d'une fois... assez rarement, mais quand c'est une archive, c'est vraiment chiant :/

T'as qu'à pas acheter des disques durs de merde
Ce ne m'est jamais arrivé non plus.

change de disque!

dans ma vie j'ai jamais eu de corruption sur un disque dur qui a fonctionné après. La seule fois ou j'ai perdu des billes c'était à cause d'un disque mort, et le FS aurait rien changé, ou a cause d'une fausse manip de ma part, et le FS aurait pas pu faire gd chose non plus.

Je suppose que c'est pareil pour la journalisation, ça ne sert à rien ?

non, la journalisation sert. Mais les checksums me semblent pas vitaux.

Les checksums sont d'autant plus importants pour les disques de backup, mais même sur les disques principaux, il est important de détecter les corruptions.
La techno SMART ne fait pas tout et ne renseigne en réalité pas très bien sur l'état du disque (j'avais vu une news en 2007 sur LWN qui présentait les résultats de plusieurs années d'utilisation des disques sur la population importante de disques hétérogènes de Google)...

Même si les technos de fabrication et les matériaux ont évolué depuis, mon père m'a déjà raconté que du temps des VAX tournant VMS (qu'il a utilisé dans les années 80), VMS contenait du code pour monitorer en permanence les corruptions du disque (ET de la RAM, d'ailleurs). Quand VMS informait le sysadmin que le disque commençait à faire des erreurs, la procédure était de faire un backup du disque, et de le remplacer ASAP. Parce que l'expérience montrait qu'un disque qui se mettait à faire une erreur, en faisait des centaines quelques semaines plus tard.

squalyl (./551) :
non, la journalisation sert. Mais les checksums me semblent pas vitaux.

bah comme les sauvegardes, quoi ça ne sert à rien jusqu'au jour où tu te rends compte que ton archive est corrompue...

et ZFS n'apporte pas que les CRC, il y a également les snapshots qui te permettent de récupérer n'importe quelle version précédente d'un fichier (tant qu'il reste de la place, évidemment...) Comment ça doit poutrer, ça ! Bien utilisé, ça permet vraiment à n'importe qui d'avoir un système simple pour résoudre le problème des suppressions accidentelles

La taille de blocs variables, ça être pas mal pour mieux utiliser l'espace disque, même si maintenant c'est de moins en moins vital. La gestion des disques multiples a l'air mieux fichue.. tu peux combiner *facilement* plusieurs disques au sein d'un même dossier... tu peux les ajouter et les enlever de façon complètement transparente (du coup, plus besoin de répartir un gros dossier sur plusieurs disques  )

même si le checksum est pas stocké sur le disque, j'attends de mon OS qu'il me prévienne si un write() s'est mal passé. La dégradation de données sur le disque à postériori sera certes détectable, mais c'est du post mortem, quoi... et ça signale plutot un disque mort qu'un FS mal foutu. Pour le reste j'ai sha1sum.

squalyl (./554) :
même si le checksum est pas stocké sur le disque, j'attends de mon OS qu'il me prévienne si un write() s'est mal passé.

Le problème, c'est que c'est pas simple à déterminer facilement. Avec les systèmes de cache disque, l'erreur d'écriture peut survenir après l'envoi des données au niveau disque.

Flanker (./553) :
et ZFS n'apporte pas que les CRC, il y a également les snapshots qui te permettent de récupérer n'importe quelle version précédente d'un fichier (tant qu'il reste de la place, évidemment...)

Bonjour la fragmentation

Thibaut (./556) :

Flanker (./553) :
et ZFS n'apporte pas que les CRC, il y a également les snapshots qui te permettent de récupérer n'importe quelle version précédente d'un fichier (tant qu'il reste de la place, évidemment...)

Bonjour la fragmentation

Bah non, ça ne joue pas forcément à ce niveau ?

J'imagine que si. L'allocation des blocs se fera de manière contigue moins souvent dans un système où il y a une contrainte à resepcter sur l'utilisation de l'espace libre (on a des fichiers effacés, donc de la place potentielle pour allouer des séries contigues de blocs, mais c'est... potentiel).

Thibaut (./558) :
J'imagine que si. L'allocation des blocs se fera de manière contigue moins souvent dans un système où il y a une contrainte à resepcter sur l'utilisation de l'espace libre (on a des fichiers effacés, donc de la place potentielle pour allouer des séries contigues de blocs, mais c'est... potentiel).

Y'a bien "des gens" qui hurlent haut et fort qu'il ne faut pas défragmenter sous linux (ext2fs et suivants) et que c'est pour ça que les outils de defrags sont rares et souvents incompétents sur ces FS

oué, en gros, y'a un truc expérimental pour ext2, et ça marche pas pour ext3, et y'a aucun autre outil pour aucun autre fs.

pourtant certains avouent que ça finit par se fragmenter.

Mais j'ose imaginer qu'avec une usine à gaz comme zfs, ils ont réfléchi à des allocateurs de blocs un tant soit peu intelligents qui evitent la fragmentation comme ils peuvent...

Godzil (./500) :

JackosKing (./495) :
redemarres pas ton windows de la semaine et on vera

J'ai un Xp qui a un uptime de presque 5 mois, et il rame pas..

Oui enfin faut l'utiliser plus de 2% de son CPU... Mon dual core est full a 90% de la journée (compter 24h dans une journée). ET bien sous linux pas de problème au cours de la semaine, alors que sous windows, ca se dégrade a vitesse grand V.

Flanker (./516)

(J'évite de citer le gros tableau qui prend 2 pages à lui seul. )
Certains des défauts de l'ext3 que tu listes là sont corrigés par l'ext4 (on a les "extents" maintenant, et les fichiers énormes aussi (mais qui a besoin d'un fichier de plus de 2 TO à l'heure actuelle???)), d'autres par des layers différents (cryptage par exemple, cf. LUKS et d'autres solutions du même type - je rappelle que Linux sépare en couches séparées ce qui est séparable, ce n'est pas du monolithique à la ZFS).

very (./523) :
KK avoue que y'a 'longtemps' (avec lui au bout d'un moi c'est obsolète, donc longtemps ça fait quoi ? un an ? deux an ? ) linux était en dessous de Windows pour la gestion de la mémoire.

Pour le noyau 2.4 ça peut se discuter (ça fait déjà plus de 3 années, hein - FC2 avait déjà un 2.6), il y a effectivement eu des problèmes de gestion de mémoire virtuelle (il y a eu 3 gestionnaires de VM: celui d'origine de Rik van Riel, celui d'Andrea Arcangeli et celui "rmap" de Rik van Riel). Pour ceux d'avant, je ne me rappelle plus ce que ça donnait.

very (./525) :
Je veux bien, mais quand on conseil de recompiler le noyau pour intégrer un driver, je ne délire pas, non ?

Il y a des chances que celui qui t'a conseillé ça n'y connaît rien, normalement (sauf cas particuliers, genre un module qui nécessite des changements profonds dans le noyau) il suffit de compiler un module à part (ce qui va très vite et ne nécessite aucune configuration), pas la peine de tout reconfigurer et recompiler.

Quant à la date de création, c'est assez foireux comme concept: on copie un fichier en préservant sa date de modification et hop, le fichier a été créé après avoir été modifié.

Quant à la défragmentation, ça va arriver avec ext4 et les "extents", cf. e4defrag.

Kevin Kofler (./562) :

Flanker (./516)

(J'évite de citer le gros tableau qui prend 2 pages à lui seul. )Certains des défauts de l'ext3 que tu listes là sont corrigés par l'ext4 (on a les "extents" maintenant, et les fichiers énormes aussi (mais qui a besoin d'un fichier de plus de 2 TO à l'heure actuelle???)), d'autres par des layers différents (cryptage par exemple, cf. LUKS et d'autres solutions du même type - je rappelle que Linux sépare en couches séparées ce qui est séparable, ce n'est pas du monolithique à la ZFS).

mais ça ne corrige pas tous les défauts... quant au chiffrage, je suppose que ça permet naturellement de chiffrer uniquement certains fichiers ou dossiers, pas toute la partition ?

On peut trivialement créer un dossier chiffré avec un chiffreur de partition avec un "loopback mount" (la même fonctionnalité qui permet d'utiliser un ISO de CD/DVD directement sans le graver, très pratique!): on crée un fichier sur la grosse partition, on met un système de fichiers crypté dedans, et on le monte en "loopback" dans le dossier qu'on veut.

Kevin Kofler (./564) :
On peut trivialement créer un dossier chiffré avec un chiffreur de partition avec un "loopback mount" (la même fonctionnalité qui permet d'utiliser un ISO de CD/DVD directement sans le graver, très pratique!): on crée un fichier sur la grosse partition, on met un système de fichiers crypté dedans, et on le monte en "loopback" dans le dossier qu'on veut.

Ah oué... trivial... à peu près autant que de cocher une case dans les propriétés du dossier

Et le meilleur cryptage de dossiers reste toujours rm -rf. Si les données sont tellement dangereuses qu'il faut les crypter, il vaut mieux ne pas les avoir sur le disque du tout.

Pour les usages courants, genre ton dossier home crypté pour se protéger des vols de PCs portables, les solutions comme LUKS fonctionnent parfaitement (il est de toute façon conseillé d'avoir une partition home, sur un PC personnel ou familial, ça ne va pas demander beaucoup plus d'efforts d'avoir une partition home par utilisateur).

Martial Demolins (./566) :
Ce qui est récurrent chez toi Flanker, c'est que tu prends une capacité d'un OS que t'aime bien et que n'a pas Linux (genre : crypter une partition en un clic), et que tu le remets sur le tapis à chaque fois qu'on compare les OS. Fût un temps, c'était le bi-écran, maintenant, c'est le cryptage des partitions, je me demande encore ce que sera le prochain cheval de bataille.

Euh non, manque de pot, OS X ne permet pas de chiffrer uniquement des dossiers ou des fichiers... Et accessoirement, on parle de ZFS, qui est dispo sur Solaris, donc un OS que je n'utilise pas.
Par contre, KK a dit qu'on pouvait compenser ce manque d'EXT3/4 et ReiserFS une couche supplémentaire... non, ce n'est pas la même chose, et très loin d'être aussi simple...

Kevin Kofler (./567) :
Et le meilleur cryptage de dossiers reste toujours rm -rf.

Heu non, un rm -Rf reste tres facilement recuperable

Kevin Kofler (./567) :
Pour les usages courants, genre ton dossier home crypté pour se protéger des vols de PCs portables, les solutions comme LUKS fonctionnent parfaitement (il est de toute façon conseillé d'avoir une partition home, sur un PC personnel ou familial, ça ne va pas demander beaucoup plus d'efforts d'avoir une partition home par utilisateur).

Une partition home ? pourquoi faire ? à part être embêté quand l'une des deux partitions n'a plus assez de place, naturellement ^^
À la rigueur, avec Windows ça se comprend parce qu'il a beaucoup de mal à se réinstaller proprement si une installe est déjà présente, mais à part ça...