Il y a une limite a ne pas oublier : c'est qu'un file system doit assurer l'intégrité des données qu'il doit stocker, or un secteur de disque dur (encore pour un bon moment la reference du stockage commun) fait 512 octets, pas plus.
Si tu commence a répartir tes inodes (la structure qui reference un objet dans un file system) sur plusieurs secteurs, qu'est ce qui te garantit que l ón ne va pas couper l'electricité entre 2 secteurs concernant tes grosses inodes ? alors qu'un secteur s'écrit en une seule fois par le controleur du disque, sans risque de ce genre.
Donc on ne dispose pas de plus de 512 octets pour decrire un fichier dans le file system, et on a pas que son nom a conserver, mais aussi les differentes dates, id, droits, type, proprietaire ...
donc 255 ou 256, 'est deja pas si mal, ou alors il faut reinventer les disques durs avec des plus gros secteurs, mais on va tout casser. compatibilité quand tu nous tiens ...
c'est d'ailleurs pour la même raison que tu as que des fichiers de 512 octets sur ton disque ?
parce que qui te dit que tu ne vas pas avoir de problème électrique au moment où tu seras en train d'écrire ton fichier ?
et tu utilises aussi l'algo de I2BP pour assurer une tres bonne qualité de la zik que tu as sur ton disque, et ce, en 512 octets ?
si le problème n'existe pas pour un contenu de fichier, pourquoi existerait il pour un nom ? au pire, ca fini dans lost+found comme tous les blocs qui ont un problème du fait d'une coupure au mauvais moment.
non ?
[^] # Re: structure des disques
Posté par Mouns . En réponse au journal personne n'aura besoin de plus de 640ko de RAM. Évalué à 0.
Si tu commence a répartir tes inodes (la structure qui reference un objet dans un file system) sur plusieurs secteurs, qu'est ce qui te garantit que l ón ne va pas couper l'electricité entre 2 secteurs concernant tes grosses inodes ? alors qu'un secteur s'écrit en une seule fois par le controleur du disque, sans risque de ce genre.
Donc on ne dispose pas de plus de 512 octets pour decrire un fichier dans le file system, et on a pas que son nom a conserver, mais aussi les differentes dates, id, droits, type, proprietaire ...
donc 255 ou 256, 'est deja pas si mal, ou alors il faut reinventer les disques durs avec des plus gros secteurs, mais on va tout casser. compatibilité quand tu nous tiens ...
c'est d'ailleurs pour la même raison que tu as que des fichiers de 512 octets sur ton disque ?
parce que qui te dit que tu ne vas pas avoir de problème électrique au moment où tu seras en train d'écrire ton fichier ?
et tu utilises aussi l'algo de I2BP pour assurer une tres bonne qualité de la zik que tu as sur ton disque, et ce, en 512 octets ?
si le problème n'existe pas pour un contenu de fichier, pourquoi existerait il pour un nom ? au pire, ca fini dans lost+found comme tous les blocs qui ont un problème du fait d'une coupure au mauvais moment.
non ?