[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