Blocking truncate()

Posted Mar 13, 2015 17:07 UTC (Fri) by cesarb (subscriber, #6266)
Parent article: Progress on persistent memory

> He suggested adding a flag to mmap() to request this mode of operation. That should reduce the surprise factor as it makes the behavior dependent on what is being mapped.

Having truncate() block potentially forever, without a special flag to the truncate() call, would still be surprising behavior. Say a sysadmin notices a "hung" process; how would he find that it was a truncate() waiting for a mmap(), and most important, how would he find which are the files involved and which process he should kill so the truncate() goes ahead?

It would be as annoying as "mandatory locking".

We already sort of have that problem with NFS, but with NFS it's easy to find (check the server for all mounted filesystems to see if any isn't responding) and solve (reboot the hung server).

Blocking truncate()

Posted Mar 13, 2015 21:16 UTC (Fri) by zlynx (guest, #2285) [Link]

strace would show the program blocking on truncate(14) for example.

Then lsof would show that file handle 14 is /nvm/datafile.

fuser -v /nvm/datafile shows the programs using it.

I think that sequence of commands would do the trick.

Blocking truncate()

Posted Mar 15, 2015 14:52 UTC (Sun) by pflugstad (subscriber, #224) [Link]

And wouldn't you want to use huge pages for something like that? That would cut down on overhead quite a bit...

Blocking truncate()

Posted Apr 9, 2015 18:53 UTC (Thu) by Jandar (subscriber, #85683) [Link]

IMHO it's not good to block the truncate() syscall instead remember the intended file-size. I seen it like an unlink() on a file which has an open fd, the resource is released after the last usage ended.

What happens if a write enlarges the file to have a new backing for the mmapped region? If the truncate is blocked, would it revert this enlargement after unmap()?

Blocking the truncating process opens needlessly a can of worms.