On Mon, Mar 04, 2002 at 03:12:44PM +0000, Alan Cox wrote:
> > another inode after the trunc op would break unix semantics. In order to
> > work, you'd have to use a new inode (in .undelete, of course), copy, then do
> > the actual trunc call.
> > This would make truncation expensive, whereas before it was pretty fast.
> > Modifying unlink will probably suffice.
>
> You would need to hook the truncate/unlink paths in the file system. If
> you are doing it within the fs it becomes cheap (at least for ext2) - as
> you can simply reassign the data blocks to a new inode, stuff the new inode
> into the magic "stuff we deleted" directory and continue.
It may make it easier to put this part in the kernel, but is there some way
to make it filesystem generic?
Undelete on truncate isn't a high priority, but if we do have it, it would
be nice if all of the filesystems that follow unix semantics (and maybe the
others too) could use generic VFS ops for this feature.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 07 2002 - 21:00:33 EST