[RTEMS-gsoc2011] ISO9660 GSoC project report

[Christophe Huriaux]

Thanks for your answers,

2011/7/7 Chris Johns <chrisj at rtems.org>

> On 6/07/11 9:29 PM, Christophe Huriaux wrote:
>
>> Hi,
>>
>>    I have good news concerning the iso9660 file-system implementation
>> project as part of the GSoC. My test workbench is now able to mount an
>> iso9660 volume, to navigate throughout the directory structure and to
>> perform basic file operations (open/read/close) on the volume. The
>> source device for the mount operation can be either a block device (and
>> the device access is thus handled by a libblock bdbuf layer) or a
>> regular file on another file-system (device I/O is handled with standard
>> posix call in this case).
>>
>>
> Great work and well done.
>
>
>    Until the GSoC mid-term deadline (next week), I will concentrate my
>> efforts on finishing the file management part (the FS still miss some
>> calls like seek() ), cleaning up the code and add the missing doxygen
>> documentation.
>>
>
> Nice.
>
>
>    My further work will firstly be dedicated to the improvement of the
>> cache for this file-system. Since it's a read-only FS I plan to
>> implement a FIFO cache based on block access time : when a new block has
>> to be put in the cache, the oldest (from an access time point of view)
>> is uncached (the smallest entity in the ISO is called a sector and is
>> 2,048 bytes long). This method should help often accessed blocks to stay
>> in the cache while the less accessed will be discarded. However, I still
>> need some comments on this point since I'm not a cache manager guru. :-)
>>
>
> How important is the need for an extra layer of cache over the libblock
> cache ? A CDROM is not a fast device so caching is important.
>
> The libblock cache will cache at the sector size if configured to do so.
> The media block size for ATA(PI?) is 512 bytes how-ever the file system
> layer can specify the file system block size to the libblock cache.
>
>
 I understand that adding others level of caching over libblock may not be
beneficial to the filesystem performance, but what about the direct device
I/O layer ? Should I rely on the underlying filesystem cache (which may or
may not use libblock) in this case ?


>
>    Another point of the implementation on which I'd like some comments
>> is the filename formatting. Currently the iso9660 implementation handles
>> only the real ISO9660 standard-compliant volumes without extension,
>> therefore filenames and directory names are limited to a tiny character
>> set consisting of only capital letters, digits and underscore. If one
>> mounts such an ISO volume under Linux, the names will be displayed and
>> handled lowercase, while others OS leave them unchanged. I wonder how
>> the RTEMS implementation should handle them : unchanged (uppercase),
>> lowercase, case-insensitive, application-defined ?
>>
>
> Can this be a mount option ?
>

 Of course, I have not thought of this alternative, it's way better to
decide at runtime.


>
> Chris
>

Regards,
Christophe Huriaux
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20110707/56b3d526/attachment.html>