[mythtv-users] File System Recommendation?

Brian Wood beww at beww.org
Mon Apr 3 03:54:00 UTC 2006


On Apr 2, 2006, at 9:37 PM, Steven C. Liu wrote:

> Brian Wood wrote:
>> On Apr 2, 2006, at 9:01 PM, Richard Dale wrote:
>>
>>
>>>> I'm using ext3 on a RAID-0 system. Who the heck cares if it takes a
>>>> second or two to delete a 1-hour show ??
>>>>
>>> Here's an interesting solution - the recording could be flagged for
>>> deletion
>>> and then deleted in a background thread.  So, even if it takes a
>>> while it's
>>> the background thread that has to wait on I/O, not the foreground  
>>> user
>>> interface.
>>>
>>>
>> I don't know for sure how the kernel and ext3 handle these things but
>> I would *think* that the system is smart enough to not block on a
>> delete. I'd think the file would be marked as deleted in the cache
>> and the actual "deletion" (really just marking space as available)
>> would be carried out when IO was available.
>>
>> Or is that what makes the newer filesystems "better" ?
>>
>> I've certainly never noticed any delays even when I delete a dozen or
>> more shows rapidly, If I had I would have switched to another FS
>> (maybe).
>
> Brian,
>
> How you described it is how a filesystem works.  A write(3) and a  
> remove(3) only causes the fileop to be cached and the inode to  
> marked as "dirty".  The periodic sync then writes to disk and  
> clears the "dirty" inodes.
>
> JFS is a journaling fs, which means (at least to me) that fileops  
> are recorded in an index for that filesystem and your view of said  
> filesystem is in the form of "snapshots".  Writes and deletions are  
> merely record changes in a specialized database.
>

Makes sense to me. I think ext3 is just a journaling ext2. Linux  
makes heavy use of RAM to cache FS data as well, based on what I see  
of memory allocations.

So why do I read so much bilgewater about how "long" ext3 takes to  
delete a file and why I shouldn't use it for that reason??




More information about the mythtv-users mailing list