From: Vitaly Fertman <vitaly@sun.com>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] on-disk SOM attributes [former storing SOM epoch in EA]
Date: Tue, 19 Feb 2008 23:33:52 +0300 [thread overview]
Message-ID: <200802192333.52663.vitaly@sun.com> (raw)
In-Reply-To: <47BAA607.1000600@sun.com>
Hi All,
Besides the question Alex asked, there are some more issues
I would like to discuss, so let me list all of them here.
1) where to store on-disk IOepoch on MDS -- this question
was described in the Alex's initial "storing SOM epoch in EA"
email, so I will not repeat it here.
2) where to store SOM-ENABLE flag in inode?
currently it is stored in inode flags, but it may be not
acceptable for DMU. If so, we will probably need to move it
to the place we will store on-disk IOepoch in (EA?).
I also want to mention that on-disk IOepoch is needed at the
attribute update time only, to be sure we write newer attributes.
Whereas SOM-ENABLE flag is needed more often, thus it is also
checked when we tell a client size is valid at getattr.
3) how to avoid e2fsck zeroing i_blocks on MDS?
we could patch e2fsck, or alternatively store i_blocks copy
in inode that fsck does not know about, e.g. in the same EA.
As i_blocks is needed on each getattr, it is worth to store
it along with SOM-ENABLE flag.
Please advise.
--
Vitaly
prev parent reply other threads:[~2008-02-19 20:33 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-19 9:48 [Lustre-devel] storing SOM epoch in EA Alex Zhuravlev
2008-02-19 10:28 ` Yuriy Umanets
2008-02-19 10:30 ` Alex Zhuravlev
2008-02-19 10:38 ` Yuriy Umanets
2008-02-19 10:59 ` Vitaly Fertman
2008-02-19 11:11 ` Yuriy Umanets
2008-02-19 11:18 ` Alex Zhuravlev
2008-02-19 12:02 ` Yuriy Umanets
2008-02-19 12:09 ` Alex Zhuravlev
2008-02-19 14:28 ` Yuriy Umanets
2008-02-19 14:47 ` Alex Zhuravlev
2008-02-19 15:10 ` Yuriy Umanets
2008-02-19 12:13 ` Alex Zhuravlev
2008-02-19 14:30 ` Yuriy Umanets
2008-02-19 14:36 ` Nikita Danilov
2008-02-19 14:44 ` Yuriy Umanets
2008-02-19 14:39 ` Yuriy Umanets
2008-02-19 14:42 ` Alex Zhuravlev
2008-02-19 20:13 ` Andreas Dilger
2008-02-19 14:59 ` Mikhail Pershin
2008-02-19 15:11 ` Kalpak Shah
2008-02-19 15:23 ` Ricardo M. Correia
2008-02-19 15:14 ` Yuriy Umanets
2008-02-19 15:19 ` Alex Zhuravlev
2008-02-19 15:28 ` Vitaly Fertman
2008-02-19 15:18 ` Ricardo M. Correia
2008-02-19 16:21 ` Nikita Danilov
2008-02-19 16:27 ` Alex Zhuravlev
2008-02-20 16:10 ` Nikita Danilov
2008-02-19 15:31 ` Eric Barton
2008-02-19 15:42 ` Alex Zhuravlev
2008-02-19 20:19 ` Andreas Dilger
2008-02-19 20:33 ` Vitaly Fertman [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=200802192333.52663.vitaly@sun.com \
--to=vitaly@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.