Querying file information and concurrent file access

Posted Apr 28, 2011 19:02 UTC (Thu) by abacus (guest, #49001)
Parent article: The return of SEEK_HOLE

Are there any provisions in the FIEMAP ioctl() or SEEK_HOLE/SEEK_DATA operations to prevent concurrent write / append / unmap operations ? Does it make sense to allow a user-space process to query such information without first locking a file to prevent concurrent modifications ?

Querying file information and concurrent file access

Posted Apr 29, 2011 13:09 UTC (Fri) by CChittleborough (subscriber, #60775) [Link]

The FIEMAP facility has a FIEMAP_FLAG_SYNC option: "If this flag is set, the kernel will sync the file before mapping extents" (quoting from Documentation/filesystems/fiemap.txt). But that does not lock anything ...

Querying file information and concurrent file access

Posted Apr 29, 2011 16:01 UTC (Fri) by dark (guest, #8483) [Link]

I think it makes sense. It's not really different from a read() that might return data that's already obsolete because another process is writing there. This can be fixed with locks or other techniques (such as tar's habit of displaying a warning if the file changed), and it's up to you to use them if you want to.