| |||||||||||||
Querying file information and concurrent file accessQuerying file information and concurrent file accessPosted 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 ?
(Log in to post comments)
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 (subscriber, #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.
|
|||||||||||||