[GSoC project] Implementation of ISO9660 filesystem

Chris Johns chrisj at rtems.org
Tue Apr 5 11:54:22 UTC 2011


On 5/04/11 9:37 PM, Sebastian Huber wrote:
> 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.

The file system should be able to tell if it is in use. For a forced 
unmount any files would need to be flagged in the iop that the file is 
no longer valid.

>  We need some sort of
> reference counting and we have to protect the file system node consumer and
> producer code from concurrent access.

We need something here for other reasons as well.

>
>>
>> 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.
>

It is if you want to force an unmount.

Chris



More information about the users mailing list