Anton Aylward wrote:
Per Jessen said the following on 06/12/2011 10:14 AM:
Anton Aylward wrote:
There is a lot of /sbin that doesn't get used much; the same goes for /lib, /usr/[s]bin and /usr/lib -- and the subdirectories of /usr/lib. But it all depends... "Context is Everything" ... as I keep saying. Is this a desktop or a server? What applications?
My view is that there are things like _some_ fonts and _some_ icons/graphics that get used heavily, so perhaps parts of /usr/ and /usr/share need to be on fast access (but only parts!). Or are things like this cached? Globally or a per-user basis?
All files are cached, globally.
Yes, I understand about the page-cache, LRU and all that and "load on demand" nature of the file mapping of binaries.
But if that is so good why do we have ~/.cache and ... ~/.fonts.cache ~/.libreoffice/3-suse/user/store/.templdir.cache ~/.xdg_menu_cache ~/.local/share/mime/mime.cache ~/.mozilla/firefox/o7k1u7k5.default/extensions.cache ~/.java/deployment/cache Lots more under ~/.kde4/share/apps/
Just a guess - they're holding user/application specific data, perhaps only valid for a current session.
The way I see it we need to implement an overlay file system. There is a /usr/bin and /usr/lib on the SSD that overlays the fully populated version on the hard drive, and _somehow_ (!*!*!) the most used items get migrated up onto the SSD. SOMEHOW.
unionfs?
Yes, that implements the overlay. the SSD has priority over the hard drive.
But the question remains: how to the most used items get migrated to the SSD?
Essentially it's just another layer in the cache hierarchy, so the algorithm is probably the same. Everytime a file is read from drive2, it is copied to drive1, next time it will be picked up from drive1. Whenever a file is written to, it it is copied back to drive2. To keep the SSD-cache from overflowing, you purge files by LRU.
And as I said, how to deal with updates. Does unionfs support some kind of write-though?
I think you could probably do this _relatively_ easy with a user-space filesystem. There is already a unionfs implemented as FUSE. -- Per Jessen, Zürich (15.8°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org