>DP> hmm... what i tried is a loop device of a fixed size (100mb) on the >DP> directory that contains small files. it works fine, but is a little >DP> bit of a pain changing size.
200mb will be enough) /var/lib/pacman-cage.img 194M 40M 145M 22% /var/lib/pacman >DP> conceptually seen, small files should not be stored plainly on the fs. >DP> one idea would be to have the fs to decide what is small file what a >DP> big file and what has the potential to fragment and then on the back >DP> reshuffle things and change strategy of storage to optimise access. >DP> it would be like a library or an archive (with books in it - the real >DP> library kind of library *g*) where the people working there sort >DP> things by its properties. if single papers are filed, they end in >DP> folders. if encyclopedias are filed, whole shelfs are reserved for >DP> them. if a paper develops in an encyclopedia, then the person working >DP> there changes things. the CPU's nowadays are capable of providing the >DP> power (in the background) to do such intelligence (complex >DP> algorithms) but i am not aware of an implementation on the fs-level. >DP> there are some sql-like database-like approaches (winfs?) but this is >DP> still not facing the problem directly. >DP> we need to employ somebody to tell the fs driver where to store >DP> things... anybody knows a librarian with free time? 'Oook' :) As I know xfs have some db api... But about pacman - may be db engine should be added into it? For example own engine(not berkley db nor sqlite)? _______________________________________________ arch mailing list [email protected] http://archlinux.org/mailman/listinfo/arch
