delete file entry and free space

delete file entry and free space

[Anthony Chee]

I am doing kernel module work on file system. The module holds two variable
dir and dentry, and pass to myunlink function, which is below.

int myunlink(struct inode *dir, struct dentry *dentry) {

    int error = 0;

 down(&dir->i_sem);
 down(&dir->i_zombie);

 if (dir->i_op && dir->i_op->unlink) {
  if (d_mountpoint(dentry))
   error = -EBUSY;
  else {
   lock_kernel();
   error = dir->i_op->unlink(dir, dentry);
   unlock_kernel();

   if (!error) {
    d_delete(dentry);
   }
  }
 }

 up(&dir->i_zombie);
 if (!error)
  inode_dir_notify(dir, DN_DELETE);

 dput(dentry);
 up(&dir->i_sem);
 return error;
 }

The myunlink function is a merge from sys_unlink() and vfs_unlink(), and
remove some permission and quota syntax, as I need to force to delete the
entry. After passing the variables to the function, the entry is disappeared
while using "ls", but I found that it still occupy disk space by using
command "df". How can I also free the disk space. My target is on releasing
the disk space, and I don't care any permission or others. Or any other
method on releasing the disk space by using dir and dentry? Thanks.

Re: delete file entry and free space

[Matthew Wilcox]

On Sun, May 19, 2002 at 06:56:48AM +0800, Anthony Chee wrote:
> The myunlink function is a merge from sys_unlink() and vfs_unlink(), and
> remove some permission and quota syntax, as I need to force to delete the
> entry. After passing the variables to the function, the entry is disappeared
> while using "ls", but I found that it still occupy disk space by using
> command "df". How can I also free the disk space. My target is on releasing
> the disk space, and I don't care any permission or others. Or any other
> method on releasing the disk space by using dir and dentry? Thanks.

Unlink probably isn't enough.  On unix-like systems, space is only
reclaimed once there are no references to the inode.  If a task has
that file open, it's still got a reference.  You could unlink the file
and then truncate it to zero size, but any task which still has it open
could write to it, causing the file to be non-zero-sized.

If you don't care about that, then see sys_ftruncate for how to proceed.

-- 
Revolutions do not require corporate support.

Re: delete file entry and free space

[Anthony Chee]

>
> Unlink probably isn't enough.  On unix-like systems, space is only
> reclaimed once there are no references to the inode.  If a task has
> that file open, it's still got a reference.  You could unlink the file
> and then truncate it to zero size, but any task which still has it open
> could write to it, causing the file to be non-zero-sized.
>
> If you don't care about that, then see sys_ftruncate for how to proceed.
>
> --
> Revolutions do not require corporate support.
>

And does "rm" also involve ftruncate process?
>From manual of unlink system call, it said the space will be resused no more
process reference to it.
How can I know any process reference to the file, and does it reflect in
dentry structure? Is it dentry->d_count?

Actually, I am quite confuse on d_delete(dentry) and dput(dentry). Thanks

Re: delete file entry and free space

[Matthew Wilcox]

On Sun, May 19, 2002 at 08:25:59PM +0800, Anthony Chee wrote:
> And does "rm" also involve ftruncate process?

No.

> >From manual of unlink system call, it said the space will be resused no more
> process reference to it.
> How can I know any process reference to the file, and does it reflect in
> dentry structure? Is it dentry->d_count?

it's dentry->d_inode->i_nlink.  Read the code for iput().  Note that the
calling chain is d_delete() -> dentry_iput() -> iput().  dentry->d_count
is `how many people have a reference to this dentry', which is very
different from how many people have a reference to this inode.

> Actually, I am quite confuse on d_delete(dentry) and dput(dentry). Thanks

dput is `i have finished using this dentry now', d_delete is `i have
deleted the name this dentry refers to'.

-- 
Revolutions do not require corporate support.

Re: delete file entry and free space

[Bryan Henderson]

>> How can I know any process reference to the file, and does it reflect in
>> dentry structure? Is it dentry->d_count?
>
>it's dentry->d_inode->i_nlink.

Not exactly.  The answer to this question is dentry->d_inode->i_count.  The
number of references by processes to the inode (of course each of these
references could be a summary of multiple sub-references).  The i_nlink
field tells how many directory entries refer to the file.  Both have to be
zero before the file can be deleted.

It's worth explaining here what we can't explain too often in the Unix
world:  There is no system call, and consequently no shell command, to
delete a file.  The system automatically deletes a file as soon as it
becomes impossible for anyone ever to access the file again, and not
before.  The unlink() system call, like the Rm program that is based on it,
removes a link to the file (a directory entry that refers to it).  That
gets the file closer to that condition where it can never be accessed
again, but that's all.