dead

[legacy]

• 

dead

[cdimauro]

• 

Potresti provare blocchi da 4KB, così riduci la bitmap a 32KB.

[Z80Fan]

• 

Potresti provare blocchi da 4KB, così riduci la bitmap a 32KB.

Concordo; 1 KB è veramente piccolo.


@legacy:
Se vuoi vedere un filesystem stato dell'arte, ti consiglio ZFS¹, che è uno tra i più avanzati che esistono.
Btrfs è un po' più nuovo e per molte cose è meglio di ZFS, però come implementazione non è ancora maturo, a differenza di ZFS che è affidabile e ben testato.

Ovviamente entrambi sono FS estremamente complessi, ma ci si fa un'idea di quello che oggi è disponibile.

1:
http://en.wikipedia.org/wiki/ZFS
http://open-zfs.org/wiki/Main_Page
http://zfsonlinux.org/

[lucommodore]

• 

detto

quasi quasi paro un thread

fatto 

Questo sì che è un incipit coi controRazzi!

[cdimauro]

• 

NFS, però, non è un vero filesystem.

Riguardo al Tiny Filesystem, peccato per la licenza.

[cdimauro]

• 

perche' NFS no ?

Più che un filesystem è un protocollo. Nella precedente azienda ho perso il conto di quanti casini abbiamo avuto a causa sua.

non ho capito che licenza, o meglio che problema c'e' ?

La GPL è virale, per cui ne limita la diffusione/adozione. Ormai da tempo c'è un generale rallentamento di questa tipologia di licenze proprio per questo motivo, e un'ascesa di quelle più permissive e commercial-friendly.

[saimon69]

• 

[cancello tutto, sono arrivato tardi]

io personalmente direi in una MPL compatibile o meglio le MIT/apache ma la roba e' la tua...

[cdimauro]

• 

@legacy: personalmente i progetti che ho pubblicato ho usato BSD, che è la più libera, e compatibile con praticamente qualunque altro progetto.

Poi dipende anche da cosa vuoi farci. Se vuoi farci soldi, rilascia il codice con doppia licenza GPLv3 e commerciale, così ti metti al riparo dagli avvoltoi e puoi farci business.

Vedi un po' tu cosa ti conviene fare.

[cdimauro]

• 

Visto adesso:

Code license
New BSD License

[cdimauro]

• 

E' senz'altro un bel filesystem, ma se ne dovessi implementare uno preferirei che fosse strutturato in maniera più semplice, e ovviamente con meno funzionalità.

Ai tempi dell'Amiga avevo iniziato a progettare la struttura delle directory e dei metadati, e avevo un'idea su come gestire l'allocazione e la deallocazione per velocizzare queste operazioni e ridurre la frammentazione, ma poi ho avuto altro da fare e ho lasciato perdere.

[cdimauro]

• 

Sì, ma il problema di cui parlano è generale, per tutti i filesystem che consentano l'uso di metadati per i file. Anche BFS ne sarebbe affetto. Immagina di mandare un file che sta su BFS via mail, come nell'esempio citato: i metadati si perderebbero ugualmente.

[cdimauro]

• 

E' un casino. La soluzione migliore dovrebbe essere quella che le applicazioni supportino direttamente il concetto di metadata, per cui dovresti poter allegare un file a una mail, e l'applicazione automaticamente codifica anche i suoi metadati SE ce ne sono. E viceversa quando si riceve la mail. Però valli a convincere gli sviluppatori, che è già tanto se supportino il concetto di MIME...

[cdimauro]

• 

Ci stavo lavorando, ma poi ho abbandonato. Avevo definito su carta la struttura dei blocchi relativi a directory e file. Mentre a mente avevo elaborato un certo meccanismo per quanto riguarda l'allocazione e deallocazione dei blocchi.

[cdimauro]

• 

Ricordo perfettamente com'è realizzata la struttura in questione. Non è niente di quelle che hai elencato finora, ma posso dirti che non ha sicuramente la complessità di un B*Tree (o di un B-Tree in generale), ma è un po' più complicato di una bitmap.

Però non mi sono mai posto il problema di farla crescere come file; se dovessi riprendere in mano la cosa, devo pensarci, perché può essere una gran comodità. Altrimenti tocca preallocare un po' di roba, come al solito.

[cdimauro]

• 

Diciamo che se / quando avrò tempo, e nessun altro c'avrà già pensato, avrei una mezza idea di brevettare il tutto.