On Mon, Jun 20, 2011 at 06:18:57PM -0400, Christoph Hellwig wrote:
On Mon, Jun 20, 2011 at 02:32:03PM -0700, Joel Becker wrote:
Are we guaranteed that all allocation changes are locked out by
i_dio_count0? I don't think we are. The ocfs2 code very strongly
assumes the state of a
On Tue, Jun 21, 2011 at 03:40:56PM +1000, Dave Chinner wrote:
Modification of inode-i_state is not safe outside the
inode-i_lock.
We never actually set the new bit in i_state, we just use it as a key
for the hashed lookups. Or rather we try to, as I misunderstood how
wait_on_bit works, so
i_alloc_sem is a rather special rw_semaphore. It's the last one that may
be released by a non-owner, and it's write side is always mirrored by
real exclusion. It's intended use it to wait for all pending direct I/O
requests to finish before starting a truncate.
Replace it with a hand-grown
On Mon, Jun 20, 2011 at 04:15:37PM -0400, Christoph Hellwig wrote:
i_alloc_sem is a rather special rw_semaphore. It's the last one that may
be released by a non-owner, and it's write side is always mirrored by
real exclusion. It's intended use it to wait for all pending direct I/O
requests
On Mon, Jun 20, 2011 at 02:32:03PM -0700, Joel Becker wrote:
Are we guaranteed that all allocation changes are locked out by
i_dio_count0? I don't think we are. The ocfs2 code very strongly
assumes the state of a file's allocation when it holds i_alloc_sem. I
feel like we lose that
On Mon, Jun 20, 2011 at 04:15:37PM -0400, Christoph Hellwig wrote:
i_alloc_sem is a rather special rw_semaphore. It's the last one that may
be released by a non-owner, and it's write side is always mirrored by
real exclusion. It's intended use it to wait for all pending direct I/O
requests
