From: Peter J Braam <Peter.Braam@Sun.COM>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] Feed API and Changelog HLD
Date: Tue, 05 Feb 2008 06:43:48 -0700 [thread overview]
Message-ID: <47A86814.2000905@sun.com> (raw)
In-Reply-To: <47A7B8C7.1040002@sun.com>
Nathaniel Rutman wrote:
> Peter J Braam wrote:
>> On page 10 of the changelog API: recursive behavior for directories
>> in filesets must exclude directories that are mount point of other
>> filesets (as implemented for the Path Forward a few years back).
>>
>> I didn't see where ABORT sizes are discussed, but as I mentioned
>> before there are few cases where ditching records is possible.
>>
> I don't know what you're talking about with ABORT - you mean e.g. HSM
> should
> abort copying an old file if the file is modified after the copy
> starts? Or something else?
>
Hmm, this was my jetlagged head, sorry. I meant when you want to force
a truncation of the log (and throw records away), how you do handle
this? You need this mechanism, even though it will be used only rarely.
While I am writing this, I also realize that there are some logs that
may require re-compacting. This happens for the LRU logs (tracking most
recent access to files for HSM migration management) I think. The idea
for these logs is to (1) append a new record when an object is accessed,
and (2) cancel the previous record for that object using a pointer to
that record in the object. These records can be tiny (obj id / parent
obj id), but the mechanisms causes llog files to be non-empty with holes.
>> The storage of the records should be discussed. The llog headers may
>> need changes and probably the API's for canceling records will change
>> to indicate what consumer is canceling.
>>
>> It would be wise to discuss how disk full failures etc are handled in
>> some detail.
>>
> ok. Does it seem to be on the right track in general now?
At a 10,000 feet level yes. My concerns at this point are error
handling and performance and multiple consumer management. That's not so
clear yet.
- Peter -
prev parent reply other threads:[~2008-02-05 13:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-01 21:01 [Lustre-devel] Feed API and Changelog HLD Nathaniel Rutman
2008-02-04 15:17 ` Peter J Braam
[not found] ` <47A7B8C7.1040002@sun.com>
2008-02-05 13:43 ` Peter J Braam [this message]
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=47A86814.2000905@sun.com \
--to=peter.braam@sun.com \
--cc=lustre-devel@lists.lustre.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.