On Tuesday 03 June 2014, Dave Chinner wrote:
On Tue, Jun 03, 2014 at 04:22:19PM +0200, Arnd Bergmann wrote:
On Monday 02 June 2014 14:57:26 H. Peter Anvin wrote:
On 06/02/2014 12:55 PM, Arnd Bergmann wrote:
The possible uses I can see for non-ktime_t types in the kernel are:
* inodes
On Monday 02 June 2014, Joseph S. Myers wrote:
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
On Wed, 4 Jun 2014, Arnd Bergmann wrote:
On Tuesday 03 June 2014, Dave Chinner wrote:
Just ot be pedantic, inodes don't need 96 bit timestamps - some
filesystems can *support up to* 96 bit timestamps. If the kernel
only supports 64 bit timestamps and that's all the kernel can
represent,
On Wednesday 04 June 2014 13:30:32 Nicolas Pitre wrote:
On Wed, 4 Jun 2014, Arnd Bergmann wrote:
On Tuesday 03 June 2014, Dave Chinner wrote:
Just ot be pedantic, inodes don't need 96 bit timestamps - some
filesystems can *support up to* 96 bit timestamps. If the kernel
only supports
On 06/04/2014 12:24 PM, Arnd Bergmann wrote:
For other timekeeping stuff in the kernel, I agree that using some
64-bit representation (nanoseconds, 32/32 unsigned seconds/nanoseconds,
...) has advantages, that's exactly the point I was making earlier
against simply extending the internal
On Saturday 31 May 2014 18:30:49 Vyacheslav Dubeyko wrote:
By the way, what about NILFS2? Is NILFS2 ready for suggested approach
without any changes?
nilfs2 and a lot of other file systems don't need any changes for
this, because they don't assign the inode time stamp fields to
a 'struct
On Tue, 3 Jun 2014, Arnd Bergmann wrote:
I think John Stultz and Thomas Gleixner have already started looking
at how the timekeeping code can be updated. Once that is done, we should
be able to add a functional 64-bit gettimeofday/settimeofday syscall
pair. While I definitely agree this is
On Tuesday 03 June 2014 14:33:10 Joseph S. Myers wrote:
On Tue, 3 Jun 2014, Arnd Bergmann wrote:
I think John Stultz and Thomas Gleixner have already started looking
at how the timekeeping code can be updated. Once that is done, we should
be able to add a functional 64-bit
On Monday 02 June 2014 14:57:26 H. Peter Anvin wrote:
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
On Tue, Jun 03, 2014 at 04:22:19PM +0200, Arnd Bergmann wrote:
On Monday 02 June 2014 14:57:26 H. Peter Anvin wrote:
On 06/02/2014 12:55 PM, Arnd Bergmann wrote:
The possible uses I can see for non-ktime_t types in the kernel are:
* inodes need 96 bit timestamps to represent the full range of
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 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 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
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 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 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
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
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
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.
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
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More
23 matches
Mail list logo
