To view parent comment, click here.
To read all comments associated with this story, please click here.
Well, if it can really do that, while maintaining the bulk of the speed increases, and fragmentation avoidance advantages, of delayed allocation, then I am delighted. But if that is the case, why does Ted imply that it would not be?
To my knowledge, you are not "testing the wrong thing". That is exactly where I would expect to observe the problem.
Edited 2009-03-31 23:20 UTC
My understanding is that Ted is talking about a slightly different case where a large number of new files are being created simultaneously as in say a desktop environment creating its new settings on a new user and NOT closing the files while I am actually testing a single large write and since the write is not starved for resources (aka multiple files trying to get disk access), it will be committed as soon as close is called (even without fsync) since the Rawhide already has that patch.
http://cvs.fedoraproject.org/viewvc/rpms/kernel/devel/linux-2.6-ext...
At this point, this debate is rather silly since it seems most people participating in it haven't actually tested it yet and I rather hear from people actually testing this thing and providing feedback on actual problems.




Member since:
2005-07-06
Newly created files having delayed allocation didn't actually result in zero length files in my tests nor was it the problem originated stated in bug report. My tests were simply to copy a large ISO file and pull the power within 10 seconds and run md5sum on it. It worked out fine. Of course, I might be testing the wrong thing.