* Re: e4defrag and immutable files
2010-06-01 19:49 ` tytso
@ 2010-06-01 20:14 ` Greg Freemyer
2010-06-01 21:00 ` Eric Sandeen
2010-06-02 7:28 ` H. Peter Anvin
2 siblings, 0 replies; 16+ messages in thread
From: Greg Freemyer @ 2010-06-01 20:14 UTC (permalink / raw)
To: tytso; +Cc: Sunil Mushran, H. Peter Anvin, linux-ext4, Joel Becker, Mark Fasheh
On Tue, Jun 1, 2010 at 3:49 PM, <tytso@mit.edu> wrote:
> On Tue, Jun 01, 2010 at 12:32:29PM -0700, Sunil Mushran wrote:
>>
>> We (ocfs2) are looking to add a new attribute to denote files that
>> have a fixed allocation on disk. But at the same time, allow writes
>> that do not change the allocation on disk. No truncating, extending,
>> filling holes, etc. We were thinking of calling it "Static" files.
>
> That's an interesting set of semantics, and it might make sense to
> conflate that with a local disk "don't move or defrag" the file
> option. I'm not crazy with the name "static", since it could mean a
> number of other things in other contexts, but I admit I can't think of
> a better name.
FROZEN?
PRE-ALLOCATED?
FALLOCATE_ONLY?
FROZEN_ALLOCATION?
STATIC_ALLOCATION?
I like the last 2 choices myself.
Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: e4defrag and immutable files
2010-06-01 19:49 ` tytso
2010-06-01 20:14 ` Greg Freemyer
@ 2010-06-01 21:00 ` Eric Sandeen
2010-06-01 21:28 ` Sunil Mushran
2010-06-02 7:28 ` H. Peter Anvin
2 siblings, 1 reply; 16+ messages in thread
From: Eric Sandeen @ 2010-06-01 21:00 UTC (permalink / raw)
To: tytso; +Cc: Sunil Mushran, H. Peter Anvin, linux-ext4, Joel Becker, Mark Fasheh
tytso@mit.edu wrote:
> On Tue, Jun 01, 2010 at 12:32:29PM -0700, Sunil Mushran wrote:
>> We (ocfs2) are looking to add a new attribute to denote files that
>> have a fixed allocation on disk. But at the same time, allow writes
>> that do not change the allocation on disk. No truncating, extending,
>> filling holes, etc. We were thinking of calling it "Static" files.
>
> That's an interesting set of semantics, and it might make sense to
> conflate that with a local disk "don't move or defrag" the file
> option. I'm not crazy with the name "static", since it could mean a
> number of other things in other contexts, but I admit I can't think of
> a better name.
>
> - Ted
fixed-mapping files maybe?
-Eric
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: e4defrag and immutable files
2010-06-01 21:00 ` Eric Sandeen
@ 2010-06-01 21:28 ` Sunil Mushran
2010-06-01 22:26 ` tytso
0 siblings, 1 reply; 16+ messages in thread
From: Sunil Mushran @ 2010-06-01 21:28 UTC (permalink / raw)
To: Eric Sandeen; +Cc: tytso, H. Peter Anvin, linux-ext4, Joel Becker, Mark Fasheh
On 06/01/2010 02:00 PM, Eric Sandeen wrote:
> tytso@mit.edu wrote:
>
>> On Tue, Jun 01, 2010 at 12:32:29PM -0700, Sunil Mushran wrote:
>>
>>> We (ocfs2) are looking to add a new attribute to denote files that
>>> have a fixed allocation on disk. But at the same time, allow writes
>>> that do not change the allocation on disk. No truncating, extending,
>>> filling holes, etc. We were thinking of calling it "Static" files.
>>>
>> That's an interesting set of semantics, and it might make sense to
>> conflate that with a local disk "don't move or defrag" the file
>> option. I'm not crazy with the name "static", since it could mean a
>> number of other things in other contexts, but I admit I can't think of
>> a better name.
>>
>> - Ted
>>
> fixed-mapping files maybe?
>
We had thought of the term static because we wanted the inode to
be frozen. Entire metadata including the mapping. Our aim is to
do away with cluster locks for such inodes. For ios, we were planning
to limit it to only odirect and not change the mtime. That also means
no links, touch. Yes, "static" does not fit it like a glove but that's the
best we could come up with.
Sunil
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: e4defrag and immutable files
2010-06-01 21:28 ` Sunil Mushran
@ 2010-06-01 22:26 ` tytso
2010-06-01 22:51 ` Sunil Mushran
0 siblings, 1 reply; 16+ messages in thread
From: tytso @ 2010-06-01 22:26 UTC (permalink / raw)
To: Sunil Mushran
Cc: Eric Sandeen, H. Peter Anvin, linux-ext4, Joel Becker, Mark Fasheh
On Tue, Jun 01, 2010 at 02:28:08PM -0700, Sunil Mushran wrote:
>
> We had thought of the term static because we wanted the inode to
> be frozen. Entire metadata including the mapping. Our aim is to
> do away with cluster locks for such inodes. For ios, we were planning
> to limit it to only odirect and not change the mtime. That also means
> no links, touch. Yes, "static" does not fit it like a glove but that's the
> best we could come up with.
Hmm, maybe "fixed_metadata"? The one thing that worries a bit is not
touching mtime is definitely icky. I suppose it would improve
performance even on local-disk file systems if we don't update mtime,
ctime, or atime. So maybe that would be useful for folks who are
trying to extract the last bit of performance out of their enterprise
database.
One thing I do like about fixed_metadata is that as far as chattr and
lsattr is concerned 's' and 'S' are already taken. But 'f' and 'F'
aren't allocated yet. :-)
- Ted
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: e4defrag and immutable files
2010-06-01 22:26 ` tytso
@ 2010-06-01 22:51 ` Sunil Mushran
0 siblings, 0 replies; 16+ messages in thread
From: Sunil Mushran @ 2010-06-01 22:51 UTC (permalink / raw)
To: tytso; +Cc: Eric Sandeen, H. Peter Anvin, linux-ext4, Joel Becker, Mark Fasheh
On 06/01/2010 03:26 PM, tytso@mit.edu wrote:
> On Tue, Jun 01, 2010 at 02:28:08PM -0700, Sunil Mushran wrote:
>
>> We had thought of the term static because we wanted the inode to
>> be frozen. Entire metadata including the mapping. Our aim is to
>> do away with cluster locks for such inodes. For ios, we were planning
>> to limit it to only odirect and not change the mtime. That also means
>> no links, touch. Yes, "static" does not fit it like a glove but that's the
>> best we could come up with.
>>
> Hmm, maybe "fixed_metadata"? The one thing that worries a bit is not
> touching mtime is definitely icky. I suppose it would improve
> performance even on local-disk file systems if we don't update mtime,
> ctime, or atime. So maybe that would be useful for folks who are
> trying to extract the last bit of performance out of their enterprise
> database.
>
> One thing I do like about fixed_metadata is that as far as chattr and
> lsattr is concerned 's' and 'S' are already taken. But 'f' and 'F'
> aren't allocated yet. :-)
>
>
Fixed Metadata sounds good to me.
The mtime restriction is icky. But for us it is a requirement
considering we cannot safely update it without cluster locks.
I am ok if we can make that file system specific.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: e4defrag and immutable files
2010-06-01 19:49 ` tytso
2010-06-01 20:14 ` Greg Freemyer
2010-06-01 21:00 ` Eric Sandeen
@ 2010-06-02 7:28 ` H. Peter Anvin
2010-06-02 18:02 ` Sunil Mushran
2 siblings, 1 reply; 16+ messages in thread
From: H. Peter Anvin @ 2010-06-02 7:28 UTC (permalink / raw)
To: tytso; +Cc: Sunil Mushran, linux-ext4, Joel Becker, Mark Fasheh
On 06/01/2010 12:49 PM, tytso@mit.edu wrote:
> On Tue, Jun 01, 2010 at 12:32:29PM -0700, Sunil Mushran wrote:
>>
>> We (ocfs2) are looking to add a new attribute to denote files that
>> have a fixed allocation on disk. But at the same time, allow writes
>> that do not change the allocation on disk. No truncating, extending,
>> filling holes, etc. We were thinking of calling it "Static" files.
>
> That's an interesting set of semantics, and it might make sense to
> conflate that with a local disk "don't move or defrag" the file
> option. I'm not crazy with the name "static", since it could mean a
> number of other things in other contexts, but I admit I can't think of
> a better name.
>
For what it's worth, this sort of seems to be what one would expect if a
file is *both* "fixed" and "immutable".
-hpa
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: e4defrag and immutable files
2010-06-02 7:28 ` H. Peter Anvin
@ 2010-06-02 18:02 ` Sunil Mushran
2010-06-08 22:12 ` H. Peter Anvin
0 siblings, 1 reply; 16+ messages in thread
From: Sunil Mushran @ 2010-06-02 18:02 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: tytso, linux-ext4, Joel Becker, Mark Fasheh
On 06/02/2010 12:28 AM, H. Peter Anvin wrote:
> On 06/01/2010 12:49 PM, tytso@mit.edu wrote:
>> On Tue, Jun 01, 2010 at 12:32:29PM -0700, Sunil Mushran wrote:
>>>
>>> We (ocfs2) are looking to add a new attribute to denote files that
>>> have a fixed allocation on disk. But at the same time, allow writes
>>> that do not change the allocation on disk. No truncating, extending,
>>> filling holes, etc. We were thinking of calling it "Static" files.
>>
>> That's an interesting set of semantics, and it might make sense to
>> conflate that with a local disk "don't move or defrag" the file
>> option. I'm not crazy with the name "static", since it could mean a
>> number of other things in other contexts, but I admit I can't think of
>> a better name.
>>
>
> For what it's worth, this sort of seems to be what one would expect if
> a file is *both* "fixed" and "immutable".
"Immutable" means the contents do not change. But the file mappings
could change.
"Fixed mapping" means the mappings do not change but contents
could (as long as the ondisk mappings don't).
"Fixed metadata" means the entire inode (mappings included) cannot
change but the contents could (as long as the ondisk mappings don't).
(This does have the side effect of allowing writes without touching the
mtime. Like XFS' invisible i/o.)
What the boot loader needs is "Fixed mapping". I am sure there could be
other use cases for it too.
My suggestion would be to implement "Fixed mapping" as is and not have
it tied to "Fixed metadata". While we would like to use a chattr flag
for this
feature, it is not a requirement.
Sunil
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: e4defrag and immutable files
2010-06-02 18:02 ` Sunil Mushran
@ 2010-06-08 22:12 ` H. Peter Anvin
2010-06-09 1:10 ` Joel Becker
0 siblings, 1 reply; 16+ messages in thread
From: H. Peter Anvin @ 2010-06-08 22:12 UTC (permalink / raw)
To: Sunil Mushran; +Cc: tytso, linux-ext4, Joel Becker, Mark Fasheh
On 06/02/2010 11:02 AM, Sunil Mushran wrote:
> On 06/02/2010 12:28 AM, H. Peter Anvin wrote:
>> On 06/01/2010 12:49 PM, tytso@mit.edu wrote:
>>> On Tue, Jun 01, 2010 at 12:32:29PM -0700, Sunil Mushran wrote:
>>>>
>>>> We (ocfs2) are looking to add a new attribute to denote files that
>>>> have a fixed allocation on disk. But at the same time, allow writes
>>>> that do not change the allocation on disk. No truncating, extending,
>>>> filling holes, etc. We were thinking of calling it "Static" files.
>>>
>>> That's an interesting set of semantics, and it might make sense to
>>> conflate that with a local disk "don't move or defrag" the file
>>> option. I'm not crazy with the name "static", since it could mean a
>>> number of other things in other contexts, but I admit I can't think of
>>> a better name.
>>>
>>
>> For what it's worth, this sort of seems to be what one would expect if
>> a file is *both* "fixed" and "immutable".
>
> "Immutable" means the contents do not change. But the file mappings
> could change.
>
> "Fixed mapping" means the mappings do not change but contents
> could (as long as the ondisk mappings don't).
>
> "Fixed metadata" means the entire inode (mappings included) cannot
> change but the contents could (as long as the ondisk mappings don't).
> (This does have the side effect of allowing writes without touching the
> mtime. Like XFS' invisible i/o.)
>
Actually, if you're going to have three flags you might as well make
them orthogonal. That is, separate "fixed contents", "fixed mappings",
"fixed metadata" -- and don't consider the mapping as metadata for this
purpose.
-hpa
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: e4defrag and immutable files
2010-06-08 22:12 ` H. Peter Anvin
@ 2010-06-09 1:10 ` Joel Becker
2010-06-09 1:44 ` tytso
0 siblings, 1 reply; 16+ messages in thread
From: Joel Becker @ 2010-06-09 1:10 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Sunil Mushran, tytso, linux-ext4, Mark Fasheh
On Tue, Jun 08, 2010 at 03:12:04PM -0700, H. Peter Anvin wrote:
> On 06/02/2010 11:02 AM, Sunil Mushran wrote:
> > "Immutable" means the contents do not change. But the file mappings
> > could change.
> >
> > "Fixed mapping" means the mappings do not change but contents
> > could (as long as the ondisk mappings don't).
> >
> > "Fixed metadata" means the entire inode (mappings included) cannot
> > change but the contents could (as long as the ondisk mappings don't).
> > (This does have the side effect of allowing writes without touching the
> > mtime. Like XFS' invisible i/o.)
> >
>
> Actually, if you're going to have three flags you might as well make
> them orthogonal. That is, separate "fixed contents", "fixed mappings",
> "fixed metadata" -- and don't consider the mapping as metadata for this
> purpose.
I think Sunil was defining terms, not suggesting three flags ;-)
That said, it does allow all the possible characteristics in the
discussion. The only ugly think I can see is that we'll have three new
flags, plus the old immutable flag that means the same as setting all
three new flags.
Joel
--
"But all my words come back to me
In shades of mediocrity.
Like emptiness in harmony
I need someone to comfort me."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: e4defrag and immutable files
2010-06-09 1:10 ` Joel Becker
@ 2010-06-09 1:44 ` tytso
0 siblings, 0 replies; 16+ messages in thread
From: tytso @ 2010-06-09 1:44 UTC (permalink / raw)
To: H. Peter Anvin, Sunil Mushran, linux-ext4, Mark Fasheh
On Tue, Jun 08, 2010 at 06:10:28PM -0700, Joel Becker wrote:
> On Tue, Jun 08, 2010 at 03:12:04PM -0700, H. Peter Anvin wrote:
> > On 06/02/2010 11:02 AM, Sunil Mushran wrote:
> > > "Immutable" means the contents do not change. But the file mappings
> > > could change.
> > >
> > > "Fixed mapping" means the mappings do not change but contents
> > > could (as long as the ondisk mappings don't).
> > >
> > > "Fixed metadata" means the entire inode (mappings included) cannot
> > > change but the contents could (as long as the ondisk mappings don't).
> > > (This does have the side effect of allowing writes without touching the
> > > mtime. Like XFS' invisible i/o.)
> >
> > Actually, if you're going to have three flags you might as well make
> > them orthogonal. That is, separate "fixed contents", "fixed mappings",
> > "fixed metadata" -- and don't consider the mapping as metadata for this
> > purpose.
>
> I think Sunil was defining terms, not suggesting three flags ;-)
> That said, it does allow all the possible characteristics in the
> discussion. The only ugly think I can see is that we'll have three new
> flags, plus the old immutable flag that means the same as setting all
> three new flags.
Umm, what I think is being proposed --- and certainly what I think
makes sense --- is that immutable just means the data contents (just
as it has always meant), and we add two new flags, one which means
"fixed mappings", or that the location on disk must not change, and
"fixed metadata" which means all of the file metadata (not including
the mappings) must not change.
- Ted
^ permalink raw reply [flat|nested] 16+ messages in thread