Hello Jordi, Jordi Pujol: > uloop shows various advantages over other forms of copying the filesystem to > disk or to RAM. > With that there is no delay at starting the system, since the cache is > created > when the Operating System needs new parts from the original media and the > space used by the cache grows according to the reading from the original > device. > > Thank you for that tool ! > and all the rest of the assemble ! > because my Debian Live uses squasfs+lzma and aufs also.
Glad to hear that. Uloop used be one of my favorite, but I don't use it recently. > Observing that tool, The original filesystem, by now, only could be a block > device and "http" URLs. > > A suggestion, I propose the creation of the tool "ulofile": As I describe in the readme file, ulobdev.c and ulohttp.c are just samples. And you can easily apply it to various type of backends. Ah, you already did it... I read your patch in another mail... One comment. It is better to issue fstat(2) after open(2), instead of lstat(2) + open(2). Probably, to close(2) or not to close(2) in the error case doesn't matter. I'll describe about your patch and trial somewhere under sample/uloop. Thank you. Junjiro Okajima ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
