Thanks, I had definitely missed something here before.
Chris, this really means that Ext3 nesting is not just a "ref count" issue,
but that Ext3 journaling pretty much has the api for a filter to say
"include this in the transaction". By positioning the filter journaling
statements correctly, it can be included in the first transaction fragmet
(for unlink, truncate) or in the last (most other ops).
- Peter -
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Stephen C.
> Tweedie
> Sent: Saturday, October 28, 2000 10:15 AM
> To: Peter J. Braam
> Cc: Stephen C. Tweedie; Chris Mason; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: nesting transactions
>
>
> Hi,
>
> On Fri, Oct 27, 2000 at 05:21:23PM -0700, Peter J. Braam wrote:
> >
> > Chris pointed out to me that there are a few cases where
> InterMezzo has some
> > difficulties with nested transactions: look at truncate.
> Nesting here would
> > disable the possibility in Ext3 to break the transaction up.
>
> Actually, ext3 will keep truncate atomic quite happily, as long as you
> are willing for the "current" transaction to have changed once you get
> to the end of the truncate. If recovery hits one of the transaction
> breaks in the middle of a long truncate, it will find the inode on the
> list of "orphaned" inodes and will complete the truncate on recovery.
>
> In practice, this implies that you can rely on truncate being atomic
> iff it is the last operation you perform in a nested transaction.
>
> This is clearly an ext3-specific implementation property, though.
>
> Cheers,
> Stephen
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-fsdevel" in
> the body of a message to [EMAIL PROTECTED]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
