<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=iso-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Brian Wood wrote:
<blockquote cite="mid98D3405C-C3DD-4934-BF55-00F8ADC0C449@beww.org"
type="cite">
<pre wrap="">On Apr 2, 2006, at 9:01 PM, Richard Dale wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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 ??
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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).</pre>
</blockquote>
<br>
<big>Brian,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Steve<br>
</big>
</body>
</html>