File remove problem

[David Cecil]

ext Bruce Evans wrote:
> On Sat, 1 Dec 2007, David Cecil wrote:
>
>> I tried the change and it doesn't fix the non-sofdep problem.
>
> Urk.  Apparently, the extra ffs_update() activity only helps as a side
> effect.
>
>> Looking at that code got me thinking though.  I thought that a 
>> workable solution for us short term might be to call UFS_UPDATE with 
>> waitfor == 1 if the filesystem is mounted synchronous.
>
> It is strange that ithat and some other things are fully async even if 
> the
> fs is mounted (not-quite-)fully sync (or the file is open with O_SYNC).

Yes, I've noticed that too.

> I;ve thought a bit about this and decided that it is mostly a good
> optimization -- some things can be reconstructed by fsck and it is a good
> optimization to not write then synchronously.
>
> Note that waitfor == 1 in UFS_UPDATE() forces an i/o unconditionally.  

Yes, that's why in the short term I thought I'd tie it to MNT_SYNCHRONOUS.

> In
> some kernels I use a patch (posted to this list a month ago) to avoid i/o
> if the inode hasn't changed and the buffer containing the inode isn't
> dirty.  This doesn't seem to affect the bug, but it might make the bug
> larger for soft updates, since soft updates might be depending on the i/o
> to trigger a callback.
>
>> So, the scenario is:
>> mount -u -w -o sync /
>> remove file
>> mount -u -o ro /
>>
>> I observed that the second call to ffs_update with the offending 
>> vnode caused bwrite to be called, though the first call was still 
>> bdwrite.  Anyhow, the problem still occurred.  I tried clearing the 
>> B_ASYNC flag in ffs_update if bwrite is called, but still the problem 
>> occurs.  Obviously I'm missing something.
>
> When is the second update?  

The first is from ffs_truncate.  I don't know where the second call 
comes from, yet.

> Soft updates seems to trigger delayed updates
> as part of syncing, but I don't see how there could be more than one
> non-null ffs_update that does a bwrite for the non-soft updates sync 
> mounted
> case, and for the soft updates sync mounted case the sync shouldn't be
> delayed.

Unfortunately, for this weekend at least, I probably won't be able to 
investigate this too much further.  Project deadlines mean I'm going to 
have to work around this another way, unfortunately.  I'll try and get 
back to it though.

Regards,
Dave