From: nathans@aconex.com
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 07/11] xfs: Delayed logging design documentation
Date: Thu, 6 May 2010 14:17:04 +1000 (EST) [thread overview]
Message-ID: <827899224.88951273119424327.JavaMail.root@mail-au> (raw)
In-Reply-To: <921460991.88921273119221574.JavaMail.root@mail-au>
Yo,
Looking good Dave! Thanks for writing this up, it made for some
interesting lunch time reading. ;)
Here's a few typos I noticed, marked 'em up as I read along...
> +required for objects that are frequently logged. Parts inodes are
"Some parts of ..."?
> +The limitation on asynchrnous transaction throughput is the number
"asynchronous"
> +Effectively, this gives us the maximum bound out outstanding metadata
"out" -> "of"
> +formating the changes in a transaction to the log buffer. Hence we
"formatting"
> +One of the key changes that delayed logging makes to the operation of
> the
> +journalling subsystem is that is dissociates the amount of
"is" -> "it", and "disassociates" (or maybe "dissociates" is what you
meant, you chem freak you. ;)
> +recovered filesysetm is concerned, there may be many thousands of
filesystem.
> +This introduces lots of scope of deadlocks with transactions that are
"scope for deadlocks"?
> +The solution is relatively simple - it just a long time to recognise
"took a long time"
> +rewrite the vector addresses to point at the memory buffer we end up
"and rewriting the"
> with a
> +self-describing object that it can be passed to the log buffer write
"that can be"
> is entire
> +arbitrary and done to make it easy for debugging - the last items in
"is entirely"
> +crash during the write of a such a transaction could partially
> overwrites the
"partially overwrite"
> +format structure. That is, two vectors totalling roughly 150 bytes.
"totaling"
> +the write reservation (the actual space availble to the transaction)
"available"
> +checkpoint commit to complete. This background push checked and
> executed by transaction commit code.
"is checked"
> +log item completion. THe result of this is that pinning and unpinning
"The"
> +are entered and completed is the object considered clean.`
Spurious "`" there?
> + => gain confidence and fix problems reported by early
> + adopters (a.k.a. guinea pigs)
:-)
cheers.
--
Nathan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next parent reply other threads:[~2010-05-06 4:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <921460991.88921273119221574.JavaMail.root@mail-au>
2010-05-06 4:17 ` nathans [this message]
2010-05-06 6:07 ` [PATCH 07/11] xfs: Delayed logging design documentation Dave Chinner
2010-05-06 1:45 [PATCH 0/11] xfs: delayed logging Dave Chinner
2010-05-06 1:45 ` [PATCH 07/11] xfs: Delayed logging design documentation Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=827899224.88951273119424327.JavaMail.root@mail-au \
--to=nathans@aconex.com \
--cc=david@fromorbit.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox