Darren J Moffat <[EMAIL PROTECTED]> wrote: > > I poinTed him the the most recent code - please get yourself informed! > > That link is just a tar file. There is no indication at all that is an > updated version of the code already in ONNV. > > So I had to make an assumption, and given it was you the assumption is > that it is a schily version since you have produced alternate and > portable versions of many things and often point people to your > alternate versions.
I did also mention that this is a more recent version. I would not do that for inofficial code. > I'd happily be informed but a pointer to a tar file alone with no > additional info on what to expect isn't useful. Maybe a simple readme > on that page would help rather than just a tar file. I did put it out for a differente reason (to give Sun employees access to the current code) and just send a pointer to the location I created 3 weeks ago. > Glad to see you are working on improving the hsfs in OpenSolaris, thanks. Adding code to ON is a hard job.... it takes a lot more time than it takes to write the code. FYI: I did write the Joliet & ISO-9660:1999 extensions last year and the "correct hardlink" / Rock Ridge V-1.12 extension that now are waiting for integration since approx. 9 months. The next code will add support for ISO-9660 files > 4 GB (this feature is called "multi-extent" files). I did just publish the related code to enhance mkisofs in cdrtools: ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-2.01.01a32.tar.bz2 which is needed to be able to have "multi-extent" hot filesystem images for testing. The code to support Joliet and ISO-9660:1999 did already eliminate a few costly string compares and the code to support multi-extent files (> 4 GB) will also change the way directories are read. There is a hack from Moinak Ghosh that adds read-adead for hsfs _file content_ but with this extension, hsfs still causes a lot of seeks on the slow CD/DVD media. If someone has a good idea on how to find where excatly the most important bottle-neck in hsfs is located, I would be happy. I was aking because I did suspect that working on the way directory reads and file meta data caching is done could help more to speed up hsfs. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
