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/
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? We can speculate as to what is most used, and I'm sure in the case of /bin/sh and some things like kdeinit4, kwin and others determined from 'fuser' and 'lsof' we'd be correct. But then what? And as I said, how to deal with updates. Does unionfs support some kind of write-though? -- "The man who does not read good books has no advantage over the man who can't read them." --Mark Twain -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org