Re: ext3 reservation question.

[Alex Tomas <alex@clusterfs.com>]

>>>>> Andrew Morton (AM) writes:

 AM> That worked fine on ext2.  But on ext3 we have a transaction open in
 AM> prepare_write(), and the forced writeback will cause arbitrary amounts of
 AM> unexpected metadata to be pumped into the current transaction, causing the
 AM> fs to explode.

why to open transaction for ->prepare_write()? as for me, it doesn't
touch metadata to be stored on a disk.

I've partial implemented following idea:

->prepare_write() recognizes are blocks being written holes or reserved.
  it they are holes and haven't reserved yet, then set a flag about this.
  note that ->prepare_write() doesn't look right place to put reservation
  in because copy_from_user() in generic_file_aio_write_nolock() may fail.

->commit_write() looks at that flag and if it's set tries to reserve blocks.
  if reservation fails then ->commit_write() returns -ENOSPC, ext3_file_write()
  recognizes this, requests flushing and wait for free space.

->invalidatepage() drops reservation if space for page still non-allocated

->writepages() and ->writepage() drop reservation upon real allocation

I expect data=ordered mode to be very simple to implement: just put bio
submited in ->writepages() on list for correspondend transaction and
wait for completion of bio's in commit_transaction().

does this all make sense?

thanks, Alex