On Fri, May 30, 2014 at 10:01:24PM +0200, Arnd Bergmann wrote:
I picked this because it is a fairly isolated problem, as the
inode time stamps are rarely assigned to any other time values.
As a byproduct of this work, I documented for each of the file
systems we support how long the on-disk
On Sat, May 31, 2014 at 5:23 PM, Arnd Bergmann a...@arndb.de wrote:
On Saturday 31 May 2014 16:51:15 Richard Cochran wrote:
On Fri, May 30, 2014 at 10:01:24PM +0200, Arnd Bergmann wrote:
I picked this because it is a fairly isolated problem, as the
inode time stamps are rarely assigned to
On Sat, May 31, 2014 at 05:23:02PM +0200, Arnd Bergmann wrote:
It's an approximation:
(Approximately never ;)
with 64-bit timestamps, you can represent close to 300 billion
years, which is way past the time that our planet can sustain
life of any form[1].
Did you mean mean 64 bits worth
On Fri, 30 May 2014, Arnd Bergmann wrote:
a) is this the right approach in general? The previous discussion
pointed this way, but there may be other opinions.
The syscall changes seem like the sort of thing I'd expect, although
patches adding new syscalls or otherwise affecting the
On Sat, May 31, 2014 at 05:23:02PM +0200, Arnd Bergmann wrote:
On Saturday 31 May 2014 16:51:15 Richard Cochran wrote:
Why are some of the time stamp expiration dates marked as never?
It's an approximation:
Also, the term never might mean using arbitrarily long integers
as in ASN.1.
Typically they are using 64-bit signed seconds.
On May 31, 2014 11:22:37 AM PDT, Richard Cochran richardcoch...@gmail.com
wrote:
On Sat, May 31, 2014 at 05:23:02PM +0200, Arnd Bergmann wrote:
It's an approximation:
(Approximately never ;)
with 64-bit timestamps, you can represent close to
Hi Arnd,
On Fri, 2014-05-30 at 22:01 +0200, Arnd Bergmann wrote:
[snip]
Arnd Bergmann (32):
fs: introduce new 'struct inode_time'
uapi: add struct __kernel_timespec{32,64}
fs: introduce sys_utimens64at
fs: introduce sys_newfstat64/sys_newfstatat64
arch: hook up new stat and
On Sat, May 31, 2014 at 12:34:12PM -0700, H. Peter Anvin wrote:
Typically they are using 64-bit signed seconds.
Okay, that is what I wanted to know.
Thanks,
Richard
___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
On Saturday 31 May 2014 16:51:15 Richard Cochran wrote:
On Fri, May 30, 2014 at 10:01:24PM +0200, Arnd Bergmann wrote:
I picked this because it is a fairly isolated problem, as the
inode time stamps are rarely assigned to any other time values.
As a byproduct of this work, I documented
Acked-by: Srinivas Eeda srinivas.e...@oracle.com
On 06/01/2014 06:53 AM, Rickard Strandqvist wrote:
There is a risk that the variable will be used without being initialized.
This was largely found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
On Monday 02 June 2014 13:52:19 Joseph S. Myers wrote:
On Fri, 30 May 2014, Arnd Bergmann wrote:
a) is this the right approach in general? The previous discussion
pointed this way, but there may be other opinions.
The syscall changes seem like the sort of thing I'd expect, although
On 06/02/2014 12:19 PM, Arnd Bergmann wrote:
On Monday 02 June 2014 13:52:19 Joseph S. Myers wrote:
On Fri, 30 May 2014, Arnd Bergmann wrote:
a) is this the right approach in general? The previous discussion
pointed this way, but there may be other opinions.
The syscall changes seem like
On Monday 02 June 2014 12:26:22 H. Peter Anvin wrote:
On 06/02/2014 12:19 PM, Arnd Bergmann wrote:
On Monday 02 June 2014 13:52:19 Joseph S. Myers wrote:
On Fri, 30 May 2014, Arnd Bergmann wrote:
a) is this the right approach in general? The previous discussion
pointed this way, but
On Sun, 1 Jun 2014 15:53:04 +0200 Rickard Strandqvist
rickard_strandqv...@spectrumdigital.se wrote:
There is a risk that the variable will be used without being initialized.
um, no there isn't.
--- a/fs/ocfs2/dir.c
+++ b/fs/ocfs2/dir.c
@@ -3738,7 +3738,7 @@ static int
On Mon, 2 Jun 2014, Arnd Bergmann wrote:
Ok. Sorry about missing linux-api, I confused it with linux-arch, which
may not be as relevant here, except for the one question whether we
actually want to have the new ABI on all 32-bit architectures or only
as an opt-in for those that expect to stay
On 06/02/2014 12:55 PM, Arnd Bergmann wrote:
The bit that is really going to hurt is every single ioctl that uses a
timespec.
Honestly, though, I really don't understand the point with struct
inode_time. It seems like the zeroeth-order thing is to change the
kernel internal version of
On Fri, 23 May 2014 10:21:18 +0800 Xue jiufei xuejiu...@huawei.com wrote:
Please write changelogs for the patches if they are not utterly obvious?
And part of this patch was not utterly obvious. So I wrote your changelog:
: dlm_recovery_ctxt.received is unused.
:
:
17 matches
Mail list logo
