From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Andreas Dilger <adilger@clusterfs.com>
Cc: Kalpak Shah <kalpak@clusterfs.com>, linux-ext4@vger.kernel.org
Subject: Re: [PATCH] update ext4-nanosecond-patch comments
Date: Tue, 29 May 2007 17:57:43 +0530 [thread overview]
Message-ID: <465C1C3F.6030303@linux.vnet.ibm.com> (raw)
In-Reply-To: <20070529115327.GY5181@schatzie.adilger.int>
Andreas Dilger wrote:
> On May 29, 2007 13:48 +0530, Aneesh Kumar K.V wrote:
>>
>
> When the nanosecond timestamp extension was first proposed, the requirement
> from Ted and Stephen were that s_min_extra_isize was a requirement. Otherwise
> it would be possible to have a filesystem where the timestamps are going
> backward on some files due to MOST of the files supporting ns timestamps,
> but some with full EAs having to truncate the ns part away.
>
> Now, this might not be critical for some users, but for others it can be.
> Since this functionality is all here there isn't any reason to move it to
> a separate patch. The same fields will be important for the inode version
> also.
>
That is why i was thinking it should not be buried in the nanosecond
patch. Since there are multiple features depending on this, a nice patch
list would be
Add extra fields to superblock to take care of enabling feature after
file system creation
Add nano second feature
Add inode version feature
etc.
If wanted, i can attempt to split the patch as above. Let me know. If we
don't think the above is important I would say we should at least move
some of the commit message found in expand_inode_extra_isize.patch that
explains the usage to the patch that introduce these fields (nano second
patch ).
-aneesh
prev parent reply other threads:[~2007-05-29 12:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-29 5:48 [PATCH] update ext4-nanosecond-patch comments Aneesh Kumar K.V
2007-05-29 6:38 ` Kalpak Shah
2007-05-29 8:18 ` Aneesh Kumar K.V
2007-05-29 11:53 ` Andreas Dilger
2007-05-29 12:27 ` Aneesh Kumar K.V [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=465C1C3F.6030303@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=adilger@clusterfs.com \
--cc=kalpak@clusterfs.com \
--cc=linux-ext4@vger.kernel.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.