is the flush-on-close-after-truncate still needed?
After Lachlan's fix to separate on-disk and in-memory sizes, and only update on-disk when data is on-disk
(http://www.linux.sgi.com/archives/xfs/2007-05/msg00020.html) is the XFS_ITRUNCATED flag / flush-on-close-after-truncate still needed?
Thanks,
-Eric
Quoted 4 lines · Eric Sandeen
After Lachlan's fix to separate on-disk and in-memory sizes, and only update on-disk when data is on-disk
(http://www.linux.sgi.com/archives/xfs/2007-05/msg00020.html) is theXFS_ITRUNCATEDflag / flush-on-close-after-truncate still needed?
Yes, because waiting 30s before writing back /etc/fstab after it has been modified will result in lots of bug reports of /etc/fstab being zero length after a crash instead of being full of NULLs. We have had very few reports of zero length files or files with NULLs since this change was made (regardless of the file size update ordering changes). i.e. if we remove this code then the common case where NULL files occurred will return - only this time as zero length files.
Cheers,
Dave.
Quoted 6 lines · Dave Chinner
Quoted 4 lines · Eric Sandeen
After Lachlan's fix to separate on-disk and in-memory sizes, and only update on-disk when data is on-disk
(http://www.linux.sgi.com/archives/xfs/2007-05/msg00020.html) is theXFS_ITRUNCATEDflag / flush-on-close-after-truncate still needed?
Quoted 8 lines
Yes, because waiting 30s before writing back
/etc/fstabafter it has been modified will result in lots of bug reports of/etc/fstabbeing zero length after a crash instead of being full of NULLs. We have had very few reports of zero length files or files with NULLs since this change was made (regardless of the file size update ordering changes). i.e. if we remove this code then the common case where NULL files occurred will return - only this time as zero length files.
Ah, right. Ok, thanks!
-Eric
Quoted 4 lines
Cheers,
Dave.
Hmm, but file overwrite in perl/php is slow, very slow.
Which FS is best for me? XFS - perl/php overwrite problem EXT3 - 32000 subdirs limit REISER - no future
JFS - ?
DS
Quoted 20 lines · Dave Chinner
Quoted 4 lines · Eric Sandeen
After Lachlan's fix to separate on-disk and in-memory sizes, and only update on-disk when data is on-disk
(http://www.linux.sgi.com/archives/xfs/2007-05/msg00020.html) is theXFS_ITRUNCATEDflag / flush-on-close-after-truncate still needed?Yes, because waiting 30s before writing back
/etc/fstabafter it has been modified will result in lots of bug reports of/etc/fstabbeing zero length after a crash instead of being full of NULLs. We have had very few reports of zero length files or files with NULLs since this change was made (regardless of the file size update ordering changes). i.e. if we remove this code then the common case where NULL files occurred will return - only this time as zero length files.Cheers,
Dave.
Quoted 1 line · DS
Hmm, but file overwrite in perl/php is slow, very slow.
If you have control over your perl/php, perhaps you can change it to do unlink/create/write instead of truncate/write?
-Eric
Quoted 30 lines
Which FS is best for me? XFS - perl/php overwrite problem EXT3 - 32000 subdirs limit REISER - no future
JFS - ?DS
Quoted 19 lines · Dave Chinner
Quoted 4 lines · Eric Sandeen
After Lachlan's fix to separate on-disk and in-memory sizes, and only update on-disk when data is on-disk
(http://www.linux.sgi.com/archives/xfs/2007-05/msg00020.html) is theXFS_ITRUNCATEDflag / flush-on-close-after-truncate still needed?Yes, because waiting 30s before writing back
/etc/fstabafter it has been modified will result in lots of bug reports of/etc/fstabbeing zero length after a crash instead of being full of NULLs. We have had very few reports of zero length files or files with NULLs since this change was made (regardless of the file size update ordering changes). i.e. if we remove this code then the common case where NULL files occurred will return - only this time as zero length files.Cheers,
Dave.
Quoted 5 lines · Eric Sandeen
Quoted 1 line · DS
Hmm, but file overwrite in perl/php is slow, very slow.
If you have control over your perl/php, perhaps you can change it to do unlink/create/write instead of truncate/write?
Or even:
test.perl 2008-06-26 16:23:25.426869060 -0500 renamed from test.perl.orig 2008-06-26 16:22:48.163869293 -0500 +1 -1
@@ -3,7 +3,7 @@ $time=time(); for ($i=1;$i<100;$i++) { -open (SUBOR,">$i.txt"); +open (SUBOR,"+<$i.txt"); print SUBOR "aaaaaaaaaaaaaaaaaaa\n"; close (SUBOR); print "WRITE $i. FILE\n";
which gives you RW access, but does not do the truncate.
Or use sysopen. Or ...
-Eric
Thanx for interest.
There is no chance to change all scripts (too many customers and thousands and thousands perl/php skripts).
I think it isn't right way compiling own perl/php libs with needed changes on open/fopen function.
DS
Quoted 39 lines · Eric Sandeen
Quoted 1 line · DS
Hmm, but file overwrite in perl/php is slow, very slow.
If you have control over your perl/php, perhaps you can change it to do unlink/create/write instead of truncate/write?
-Eric
Quoted 30 lines
Which FS is best for me? XFS - perl/php overwrite problem EXT3 - 32000 subdirs limit REISER - no future
JFS - ?DS
Quoted 19 lines · Dave Chinner
Quoted 4 lines · Eric Sandeen
After Lachlan's fix to separate on-disk and in-memory sizes, and only update on-disk when data is on-disk
(http://www.linux.sgi.com/archives/xfs/2007-05/msg00020.html) is theXFS_ITRUNCATEDflag / flush-on-close-after-truncate still needed?Yes, because waiting 30s before writing back
/etc/fstabafter it has been modified will result in lots of bug reports of/etc/fstabbeing zero length after a crash instead of being full of NULLs. We have had very few reports of zero length files or files with NULLs since this change was made (regardless of the file size update ordering changes). i.e. if we remove this code then the common case where NULL files occurred will return - only this time as zero length files.Cheers,
Dave.
Quoted 7 lines · DS
Thanx for interest.
There is no chance to change all scripts (too many customers and thousands and thousands perl/php skripts).
I think it isn't right way compiling own perl/php libs with needed changes on open/fopen function.
Overwriting files by truncating then first and then not fsync'ing the file is a sure way to lose data if the system crashes. That's an application bug, not a filesystem bug, because the filesystem is only doing what it is told to do. XFS is ensuring that lazy application writers are unlikely to lose data when they carelessly overwriting data.
Cheers,
Dave.
Signature · 2 lines
Dave Chinner [email protected]