Re: generic_osync_inode/ext2_fsync_inode still not safe

2001-04-20 Thread Stephen C. Tweedie
Hi, On Wed, Apr 18, 2001 at 06:45:40AM -0300, Marcelo Tosatti wrote: > As far as I can see, you cannot guarantee that an inode which is unlocked > _and_ clean (accordingly to the inode->i_state) is safely on disk. > > The reason for that are calls to sync_one() which write the inode > asynchron

Re: generic_osync_inode/ext2_fsync_inode still not safe

2001-04-18 Thread Marcelo Tosatti
On Tue, 17 Apr 2001, Stephen C. Tweedie wrote: > Hi, > > On Sat, Apr 14, 2001 at 07:24:42AM -0300, Marcelo Tosatti wrote: > > > > As described earlier, code which wants to write an inode cannot rely on > > the I_DIRTY bits (on inode->i_state) being clean to guarantee that the > > inode and it

Re: generic_osync_inode/ext2_fsync_inode still not safe

2001-04-17 Thread Stephen C. Tweedie
Hi, On Sat, Apr 14, 2001 at 07:24:42AM -0300, Marcelo Tosatti wrote: > > As described earlier, code which wants to write an inode cannot rely on > the I_DIRTY bits (on inode->i_state) being clean to guarantee that the > inode and its dirty pages, if any, are safely synced on disk. Indeed --- fo

generic_osync_inode/ext2_fsync_inode still not safe

2001-04-14 Thread Marcelo Tosatti
Hi, As described earlier, code which wants to write an inode cannot rely on the I_DIRTY bits (on inode->i_state) being clean to guarantee that the inode and its dirty pages, if any, are safely synced on disk. The reason for that is sync_one() --- it cleans the I_DIRTY bits of an inode, sets the