Jan Kara <[email protected]> wrote:
>
> When a buffer is locked it does not mean that write-out is in progress. We
> have to check if the buffer is dirty and if it is we have to submit it
> for write-out. We unconditionally move the buffer to t_locked_list so
> that we don't mistake unprocessed buffer and buffer not yet given to
> ll_rw_block(). This subtly changes the meaning of buffer states in
> t_locked_list - unlock buffer (for list users different from
> journal_commit_transaction()) does not mean it has been written. But
> only journal_unmap_buffer() cares and it now checks if the buffer
> is not dirty.
Seems complex. It means that t_locked_list takes on an additional (and
undocumented!) meaning.
Also, I don't think it works. See ll_rw_block()'s handling of
already-locked buffers..
An alternative is to just lock the buffer in journal_commit_transaction(),
if it was locked-and-dirty. And remove the call to ll_rw_block() and
submit the locked buffers by hand.
That would mean that if someone had redirtied a buffer which was on
t_sync_datalist *while* it was under writeout, we'd end up waiting on that
writeout to complete before submitting more I/O. But I suspect that's
pretty rare.
One thing which concerns me with your approach is livelocks: if some process
sits in a tight loop writing to the same part of the same file, will it
cause kjournald to get stuck?
The problem we have here is "was the buffer dirtied before this commit
started, or after?". In the former case we are obliged to write it. In
the later case we are not, and in trying to do this we risk livelocking.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |