[GSoC project] Implementation of ISO9660 filesystem

Sebastian Huber sebastian.huber at embedded-brains.de
Tue Apr 5 11:37:39 UTC 2011


On 04/05/2011 01:01 PM, Chris Johns wrote:
> On 5/04/11 4:42 PM, Sebastian Huber wrote:
>> On 04/05/2011 12:36 AM, Chris Johns wrote:
>>> On 4/04/11 9:22 PM, Sebastian Huber wrote:
>>>>
>>>> one of the big problems with removable media and RTEMS is that
>>>> currently it is
>>>> impossible to unmount a file system in use.  This is a fundamental
>>>> flaw in the
>>>> RTEMS file system layer.  We should address this somehow in this
>>>> project (we
>>>> need some sort of reference counting).
>>>
>>> I see the need to be able to forcible remove a mount and any open files
>>> return an error when accessed how-ever the unmount call should be aloud
>>> to fail if the media is valid and in use and call is not forced.
>>
>> Yes.  The problem is that there is currently no way to figure out if a
>> file
>> system is in use or not.  With in use I mean that there exist some
>> nodes that
>> belong to the file system.  The nodes may be not related to a file 
>> descriptor.
>>   We have also root and current directory nodes (chroot() and chdir()).
>>
> 
> In the current code it attempts to unmount and if it fails it knows the
> file system is in use.

If you call unmount() you must ensure that the file system is not in use,
otherwise you will likely corrupt the system (e.g. heap memory use after free).
 The current EBUSY checks in unmount() are insufficient.  We need some sort of
reference counting and we have to protect the file system node consumer and
producer code from concurrent access.

> 
> What is the use case for knowing the file system is in use and not
> attempting to unmount and seeing if it fails ?
> 
> Chris

The unmount() API is not the problem.

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



More information about the users mailing list