ZFS question re: deletion during compression

Frank Leonhardt frank2 at fjl.co.uk
Thu Aug 24 09:40:42 UTC 2017

On 24/08/2017 03:23, John Levine wrote:
> In article <CAHtBMo76EwM-Q1Qr+U8VMH6kDsUkc+cb9mxARSYco=XzNxT9-Q at mail.gmail.com> you write:
>> I'm curious if ZFS didn't allow the file to be deleted while gzip was
>> working on it. Merely removing it from the directory listing. Meaning my
>> compressed file is fine.
> This isn't ZFS, this is the way Unix works.  So long as a file has a
> link in any directory or is open, it's still live.  It's only deleted
> and its space reclaimed when it has no names and is not open.
> Look at the library routine tmpfile() which returns a FILE pointer to
> a freshly created file with no name.  You can write stuff to it,
> rewind it, read it, seek around, read or write, just like any other
> file.  It goes away and its space is reclaimed when the it's closed,
> either explicitly or automatically when your program exits.

WHS and remember that a directory entry is just a pointer to the inode. 
The inode controls the file. Each inode has a reference count telling it 
how many directory entries point to it. When this drops to zero, the 
file is deleted. (There are in-memory and on-disk inodes but I'm keeping 
it simple).

The file is opened using the directory to get the inode number of the 
file. After this you can do what you like with the directory entry, 
including deleting it, moving it to another place (on the same FS), 
rename it, link it. You can also rename/move the output file while it's 
being written.

Windoze heads freak when they come across this. To Microsoft is to Limit.

Regards, Frank.

More information about the freebsd-questions mailing list