[colug-432] Troubleshooting Suggestions: File Truncation Issue
bnmille at gmail.com
Mon Jan 11 20:14:12 EST 2016
If Jeff is correct, you might get around the issue by doing the writes to a
tmpfs RAM disk, rather than to a physical disk.
On Jan 10, 2016 10:32 AM, "Jeff Frontz" <jeff.frontz at gmail.com> wrote:
> On Sat, Jan 9, 2016 at 11:13 PM, William E. T. <linux.hacker at gmail.com>
>> 1. Opens a new file
>> 2. Writes to the file
>> 3. Closes the file
>> 4. Creates a link to its real name
>> 5. Removes the original file
>> 6. stats the file to find a zero size
> Without knowing the details of the particular kernel or filesystem/RAID
> drivers involved, there is the potential for a race condition between 2/3
> and 6.
> On Unix/Linux, there is no guarantee that data has ever made it to the
> "disk" (which could include the various levels of drivers/caches in between
> your program and the actual hardware).
> From the close(2) man page notes:
> " A successful close does not guarantee that the data has been
> successfully saved to disk, as the kernel defers writes. It is not common
> for a filesystem to flush the buffers when the stream is closed. If you
> need to be sure that the data is physically stored use fsync(2). (It will
> depend on the disk hardware at this point.)"
> The only guarantee of a non-zero size would be if you called fstat (note
> the "f") on the still-open file descriptor (used in 1/2/3 above).
> You can throw in a call to sync(2) to after the close(), though depending
> on how your I/O stack is composed even that might not be perfect.
> colug-432 mailing list
> colug-432 at colug.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the colug-432