lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070529115327.GY5181@schatzie.adilger.int>
Date:	Tue, 29 May 2007 05:53:27 -0600
From:	Andreas Dilger <adilger@...sterfs.com>
To:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc:	Kalpak Shah <kalpak@...sterfs.com>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] update ext4-nanosecond-patch comments

On May 29, 2007  13:48 +0530, Aneesh Kumar K.V wrote:
> Kalpak Shah wrote:
> >On Tue, 2007-05-29 at 11:18 +0530, Aneesh Kumar K.V wrote:
> >>Also can we have a description of why s_{min, want}_extra_isize
> >>fields are added in the commit message ?
> >
> >The i_extra_isize for each inode should ideally be s_want_extra_isize
> >after inode expansion. If expansion by s_want_extra_isize is not
> >possible, then i_extra_isize must be atleast s_min_extra_isize.
> 
> My point was that the commit message of ext4-nanosecond-patch should 
> explain the usage scenario for these variables. We may want to move the
> commit message of ext4_expand_inode_extra_isize.patch reworded to this.
> 
> BTW i also think that adding s_{min, want}_extra_isize can be a separate 
> patch altogether.

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.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ