Le noyau de Mac OS X sur Lion n'arrête pas de planter. sur du HFS+ il m'est arrivé de perde des fichiers ou d'en avoir des corrompus.
Commence par tester ta RAM.
J'ai un temps très bien connu les structures de données d'HFS+, et ce FS n'a rien d'intrinsèquement fragile au point d'être susceptible de péter tout seul. Certes ce n'est ni de l'ext4, ni du btrfs, et oui certains concepts sont relous comme le fait de mettre des structures dans des fichiers spéciaux éventuellement extensibles (certains bouts de code doivent être écrit avec beaucoup d'attention pour éviter de partir en vrille en cas d'erreur du FS mais c'est un peu nécessaire pour tous les FS...), mais j'ai déjà codé une implé capable de diminuer la taille d'une partition HFS+ sans perte de donnée y compris lors d'une interruption violente impromptue n'importe quand, donc faire de la fiabilité avec HFS+ n'a rien d'intrinsèquement impossible.
Il est sans doute un peu lent si l'on tente de compiler un noyau Linux dessus ou autre tache qu'affectionne Linus Torvald, c'est peut être ce qui a poussé ce dernier à déclarer péremptoirement et du haut de son infaillibilité que c'était du caca (ou je ne sais plus quel autre adjectif guère plus élogieux). Pour remettre les choses en perspective, la conception du caca en question est une simple évolution de HFS (vraiment le portage pour passer d'une implé HFS à une implé de HFS+ est assez facile), et la conception de HFS date d'avant 1985, date à laquelle Linus n'y aurait peut-être bien rien compris (il ne savait pas implémenter un "printf" quand il a commencé Linux IIRC).
Et pas grand monde peut se targuer d'avoir fait un design de FS aussi durable avec une seule évolution profonde (HFS->HFS+) et pourtant ne remettant pas en cause l'architecture du FS, pas non plus remise en cause lors de l'ajout du journaling, des hotfiles, etc.
[^] # Re: Jobs est cité dans le livre de management
Posté par Guillaume Knispel . En réponse au journal Steve Jobs décortiqué dans le New Yorker. Évalué à 8.
Commence par tester ta RAM.
J'ai un temps très bien connu les structures de données d'HFS+, et ce FS n'a rien d'intrinsèquement fragile au point d'être susceptible de péter tout seul. Certes ce n'est ni de l'ext4, ni du btrfs, et oui certains concepts sont relous comme le fait de mettre des structures dans des fichiers spéciaux éventuellement extensibles (certains bouts de code doivent être écrit avec beaucoup d'attention pour éviter de partir en vrille en cas d'erreur du FS mais c'est un peu nécessaire pour tous les FS...), mais j'ai déjà codé une implé capable de diminuer la taille d'une partition HFS+ sans perte de donnée y compris lors d'une interruption violente impromptue n'importe quand, donc faire de la fiabilité avec HFS+ n'a rien d'intrinsèquement impossible.
Il est sans doute un peu lent si l'on tente de compiler un noyau Linux dessus ou autre tache qu'affectionne Linus Torvald, c'est peut être ce qui a poussé ce dernier à déclarer péremptoirement et du haut de son infaillibilité que c'était du caca (ou je ne sais plus quel autre adjectif guère plus élogieux). Pour remettre les choses en perspective, la conception du caca en question est une simple évolution de HFS (vraiment le portage pour passer d'une implé HFS à une implé de HFS+ est assez facile), et la conception de HFS date d'avant 1985, date à laquelle Linus n'y aurait peut-être bien rien compris (il ne savait pas implémenter un "printf" quand il a commencé Linux IIRC).
Et pas grand monde peut se targuer d'avoir fait un design de FS aussi durable avec une seule évolution profonde (HFS->HFS+) et pourtant ne remettant pas en cause l'architecture du FS, pas non plus remise en cause lors de l'ajout du journaling, des hotfiles, etc.