Russell Coker wrote: >> But adding an explicit fsync() is trivial as soon as I can get a >> reproducer. > > You want to be able to repeatably trigger a race-condition before you fix it? > > To cause this race condition you must first use a file-system that is > optimised for performance (EG XFS) so that it will allow long cache > write-back times and also do write-related tasks after closing the file (EG > assigning disk blocks to the file after close() so that it knows the length). > > Then put some load on the system while installing an RPM, and then trigger a > hardware reset shortly after rpm exits.
I have some patches for busybox that allow rpm packages to be used there. Often with embedded it is flash behind the filesystem, so I make it call sync() on exit for just this scenario. I don't think fsync() for individual files is really a fair answer, it's fine if it just uses the normal filesystem APIs per-file. But after the transaction is complete, and you walk away thinking you did complete an rpm transaction, there is a case for adding a sync() to make sure everything you think you have done is truly committed to physical storage (maybe it does it already, I dunno). On the one hand this is a relatively low probability issue for a desktop box but on the other hand it is pretty cheap. -Andy ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
