Message135865
> So I think you should stick with the previous version (well, if the
> full sync fails on other FDs, then it's another story, but in that
> case it should just be dropped altogether if it's not reliable...).
Strong stuff.
*This* is the version which should have been implemented from the
beginning, but Apple states
F_FULLFSYNC Does the same thing as fsync(2) then asks the drive to
flush all buffered data to the permanent storage
device (arg is ignored). This is currently
implemented on HFS, MS-DOS (FAT), and Universal Disk
Format (UDF) file systems.
and i thought
- fsync (maybe move buffers to Queue; do reorder Queue as approbiate)
- do call fsys impl. to .. whatever
That's why i had a version of the patch which did 'fsync();fcntl();'
because it would have been an additional syscall but the fsync()
part would possibly have been essentially "skipped over" ..unless..
Linux RC scripts had 'sync && sync && sync' but it does not seem
to be necessary any more (was it ever - i don't know).
But who knows if that fcntl will fail on some non-noted fsys?
I think it's better to be on the safe side.
Quoting you, Charles-François
> People requiring write durability will probably manage to find
> this full_sync parameter
and if they do they thus really strive for data integrity, so call
fsync() as a fallback for the security which Apple provides.
Also: we cannot let os.fsync() fail with ENOTTY!?
> By the way, it's "appropriate", not "approbiate". You made the same
> typo in your patch.
8~I That was not a typo. Thanks.
I'll changed that. |
File name |
Uploaded |
11877.8.diff
|
sdaoden,
2011-05-12.20:56:55
|
|
Date |
User |
Action |
Args |
2011-05-12 20:56:56 | sdaoden | set | recipients:
+ sdaoden, ronaldoussoren, pitrou, vstinner, nadeem.vawda, neologix, santoso.wijaya |
2011-05-12 20:56:55 | sdaoden | link | issue11877 messages |
2011-05-12 20:56:55 | sdaoden | create | |
|