Strange ZFS problem, filesystem claims to be full when clearly not full

[Markus Gebert]

On 01.10.2010, at 00:15, Danny Carroll wrote:

>> 
>> If the process causing this is gone, or is working correctly (seeing
>> that the fs is no longer growing, I hope),
>> can dead unlinked files still remain, is there a way to purge them?
> 
> I can't remember exactly what happens and it's probably different for
> each flavour of unix and *nux.
> If a file is deleted, then the directory entry for the inode is
> de-linked.   If it's the last link to that inode then usually that inode
> is freed.
> 
> But when a process holds a handle to a file when it's deleted, then the
> reclaim does not happen AFAIK until *after* the file handle is closed.
> 
> <speculation>
> I wonder what happens when, if a file handle is opened for writing,
> someone else comes along and truncates the file.  
> Perhaps a the seek position of the open handle is reset to 0, or perhaps
> (not likely) a write operation after truncation would result in an error.
> </speculation>

AFAIK the file handle offset won't get reset to anything unless O_APPEND was used to open the file (maybe there are other special cases). In either case, the write will _not_ fail due to an offset beyond EOF, instead a hole is created and the new data gets written after that. (see man lseek(2))

The hole won't use disk space (as shown by df or zfs list), but is considered part of the file size (as shown by ls). In other words, truncating might free disk space, no matter what offsets other filehandles have.

However I don't see the point here. If the OP knows the file, he may as well delete it to free disk space. If he doesn't, or it's inaccessible (deleted but referenced), truncating isn't an option.


Markus