Re: [Ocfs2-devel] [RFC 00/32] making inode time stamps y2038 ready
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 format can work[1]. Why are some of the time stamp expiration dates marked as never? Thanks, Richard ___ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel
Re: [Ocfs2-devel] [RFC 00/32] making inode time stamps y2038 ready
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 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 format can work[1].
Why are some of the time stamp expiration dates marked as never?
It's an approximation:
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].
FWIW, the 48-bit second limit of befs marked never happens sooner
than the 32-bit day limit of affs marked as Y11760870.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel
Re: [Ocfs2-devel] [RFC 00/32] making inode time stamps y2038 ready
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 of seconds? 2^64 / (3600*24*365) = 584,942,417,355 That is more than 300 billion years, and still, it is not quite the same as never. In any case, that term is not too helpful in the comparison table, IMHO. One could think that some sort of clever running count relative to the last mount time was implied. Thanks, Richard [1] You are forgetting the immortal robotic overlords. ___ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel
Re: [Ocfs2-devel] [RFC 00/32] making inode time stamps y2038 ready
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 kernel/userspace interface (as opposed to those relating to an individual filesystem) should go to linux-api as well as other relevant lists. -- Joseph S. Myers jos...@codesourcery.com ___ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel
Re: [Ocfs2-devel] [RFC 00/32] making inode time stamps y2038 ready
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. Thanks, Richard ___ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel
Re: [Ocfs2-devel] [RFC 00/32] making inode time stamps y2038 ready
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 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 of seconds? 2^64 / (3600*24*365) = 584,942,417,355 That is more than 300 billion years, and still, it is not quite the same as never. In any case, that term is not too helpful in the comparison table, IMHO. One could think that some sort of clever running count relative to the last mount time was implied. Thanks, Richard [1] You are forgetting the immortal robotic overlords. -- Sent from my mobile phone. Please pardon brevity and lack of formatting. ___ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel
Re: [Ocfs2-devel] [RFC 00/32] making inode time stamps y2038 ready
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 utimes syscalls
isofs: fix timestamps beyond 2027
fs/nfs: convert to struct inode_time
fs/ceph: convert to 'struct inode_time'
fs/pstore: convert to struct inode_time
fs/coda: convert to struct inode_time
xfs: convert to struct inode_time
btrfs: convert to struct inode_time
ext3: convert to struct inode_time
ext4: convert to struct inode_time
cifs: convert to struct inode_time
ntfs: convert to struct inode_time
ubifs: convert to struct inode_time
ocfs2: convert to struct inode_time
fs/fat: convert to struct inode_time
afs: convert to struct inode_time
udf: convert to struct inode_time
fs: convert simple fs to inode_time
logfs: convert to struct inode_time
hfs, hfsplus: convert to struct inode_time
gfs2: convert to struct inode_time
reiserfs: convert to struct inode_time
jffs2: convert to struct inode_time
adfs: convert to struct inode_time
f2fs: convert to struct inode_time
fuse: convert to struct inode_time
scsi: fnic: use current_kernel_time() for timestamp
fs: use new inode_time definition unconditionally
By the way, what about NILFS2? Is NILFS2 ready for suggested approach
without any changes?
Thanks,
Vyacheslav Dubeyko.
___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel
Re: [Ocfs2-devel] [RFC 00/32] making inode time stamps y2038 ready
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 https://oss.oracle.com/mailman/listinfo/ocfs2-devel
Re: [Ocfs2-devel] [RFC 00/32] making inode time stamps y2038 ready
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 for each of the file systems we support how long the on-disk format can work[1]. Why are some of the time stamp expiration dates marked as never? It's an approximation: 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]. Arnd [1] http://en.wikipedia.org/wiki/Timeline_of_the_far_future ___ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel
Re: [Ocfs2-devel] [PATCH] fs: ocfs2: dir.c: Cleaning up uninitialized variables
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 rickard_strandqv...@spectrumdigital.se --- fs/ocfs2/dir.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c index 0717662..27aa4a1 100644 --- a/fs/ocfs2/dir.c +++ b/fs/ocfs2/dir.c @@ -3738,7 +3738,7 @@ static int ocfs2_dx_dir_rebalance(struct ocfs2_super *osb, struct inode *dir, int credits, ret, i, num_used, did_quota = 0; u32 cpos, split_hash, insert_hash = hinfo-major_hash; u64 orig_leaves_start; - int num_dx_leaves; + int num_dx_leaves = 0; struct buffer_head **orig_dx_leaves = NULL; struct buffer_head **new_dx_leaves = NULL; struct ocfs2_alloc_context *data_ac = NULL, *meta_ac = NULL; ___ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel
Re: [Ocfs2-devel] [RFC 00/32] making inode time stamps y2038 ready
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 patches adding new syscalls or otherwise affecting the kernel/userspace interface (as opposed to those relating to an individual filesystem) should go to linux-api as well as other relevant lists. 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 around for another 24 years. Two more questions for you: - are you (and others) happy with adding this type of stat syscall (fstatat64/fstat64) as opposed to the more generic xstat that has been discussed in the past and that never made it through the bike- shedding discussion? - once we have enough buy-in from reviewers to merge this initial series, should we proceed to define rest of the syscall ABI (minus driver ioctls) so glibc and kernel can do the conversion on top of that, or should we better try to do things one syscall family at a time and actually get the kernel to handle them correctly internally? Arnd ___ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel
Re: [Ocfs2-devel] [RFC 00/32] making inode time stamps y2038 ready
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 the sort of thing I'd expect, although patches adding new syscalls or otherwise affecting the kernel/userspace interface (as opposed to those relating to an individual filesystem) should go to linux-api as well as other relevant lists. 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 around for another 24 years. Two more questions for you: - are you (and others) happy with adding this type of stat syscall (fstatat64/fstat64) as opposed to the more generic xstat that has been discussed in the past and that never made it through the bike- shedding discussion? - once we have enough buy-in from reviewers to merge this initial series, should we proceed to define rest of the syscall ABI (minus driver ioctls) so glibc and kernel can do the conversion on top of that, or should we better try to do things one syscall family at a time and actually get the kernel to handle them correctly internally? 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 struct timespec to have a 64-bit time... it isn't just about inodes. We then should be explicit about the external uses of time, and use accessors. -hpa ___ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel
Re: [Ocfs2-devel] [RFC 00/32] making inode time stamps y2038 ready
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 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 kernel/userspace interface (as opposed to those relating to an individual filesystem) should go to linux-api as well as other relevant lists. 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 around for another 24 years. Two more questions for you: - are you (and others) happy with adding this type of stat syscall (fstatat64/fstat64) as opposed to the more generic xstat that has been discussed in the past and that never made it through the bike- shedding discussion? - once we have enough buy-in from reviewers to merge this initial series, should we proceed to define rest of the syscall ABI (minus driver ioctls) so glibc and kernel can do the conversion on top of that, or should we better try to do things one syscall family at a time and actually get the kernel to handle them correctly internally? 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 struct timespec to have a 64-bit time... it isn't just about inodes. We then should be explicit about the external uses of time, and use accessors. I picked these because they are fairly isolated from all other uses, in particular since inode times are the only things where we really care about times in the distant past or future (decades away as opposed to things that happened between boot and shutdown). For other kernel-internal uses, we may be better off migrating to a completely different representation, such as nanoseconds since boot or the architecture specific ktime_t, but this is really something to decide for each subsystem. I just tried building an arm32 kernel with a s64 time_t, and that failed horribly, I get linker errors for missing 64-bit divides and lots of warnings for code that expects time_t pointers to functions taking a 'long' or vice versa. I also think the only way to maintain ABI compatibility is to separate the internal uses from the interface, which means auditing all code in the end. Arnd ___ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel
Re: [Ocfs2-devel] [PATCH] fs: ocfs2: dir.c: Cleaning up uninitialized variables
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 ocfs2_dx_dir_rebalance(struct ocfs2_super *osb, struct inode *dir, int credits, ret, i, num_used, did_quota = 0; u32 cpos, split_hash, insert_hash = hinfo-major_hash; u64 orig_leaves_start; - int num_dx_leaves; + int num_dx_leaves = 0; struct buffer_head **orig_dx_leaves = NULL; struct buffer_head **new_dx_leaves = NULL; struct ocfs2_alloc_context *data_ac = NULL, *meta_ac = NULL; If ocfs2_dx_dir_kmalloc_leaves() returns non-zero, num_dx_leaves will have been initialized. ___ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel
Re: [Ocfs2-devel] [RFC 00/32] making inode time stamps y2038 ready
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 around for another 24 years. For glibc I think it will make the most sense to add the support for 64-bit time_t across all architectures that currently have 32-bit time_t (with the new interfaces having fallback support to implementation in terms of the 32-bit kernel interfaces, if the 64-bit syscalls are unavailable either at runtime or in the kernel headers against which glibc is compiled - this fallback code will of course need to check for overflow when passing a time value to the kernel, hopefully with error handling consistent with whatever the kernel ends up doing when a filesystem can't support a timestamp). If some architectures don't provide the new interfaces in the kernel then that will mean the fallback code in glibc can't be removed until glibc support for those architectures is removed (as opposed to removing it when glibc no longer supports kernels predating the kernel support). Two more questions for you: - are you (and others) happy with adding this type of stat syscall (fstatat64/fstat64) as opposed to the more generic xstat that has been discussed in the past and that never made it through the bike- shedding discussion? I am. - once we have enough buy-in from reviewers to merge this initial series, should we proceed to define rest of the syscall ABI (minus driver ioctls) so glibc and kernel can do the conversion on top of that, or should we better try to do things one syscall family at a time and actually get the kernel to handle them correctly internally? I don't have any comments on that ordering question. -- Joseph S. Myers jos...@codesourcery.com ___ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel
Re: [Ocfs2-devel] [RFC 00/32] making inode time stamps y2038 ready
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 struct timespec to have a 64-bit time... it isn't just about inodes. We then should be explicit about the external uses of time, and use accessors. I picked these because they are fairly isolated from all other uses, in particular since inode times are the only things where we really care about times in the distant past or future (decades away as opposed to things that happened between boot and shutdown). If nothing else, I would expect to be able to set the system time to weird values for testing. So I'm not so sure I agree with that... For other kernel-internal uses, we may be better off migrating to a completely different representation, such as nanoseconds since boot or the architecture specific ktime_t, but this is really something to decide for each subsystem. Having a bunch of different time representations in the kernel seems like a real headache... -hpa ___ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel
Re: [Ocfs2-devel] [PATCH] ocfs2: remove some unused codes
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.
:
: ocfs2_should_refresh_lock_res() can only return 0 or 1, so the error
: handling code in ocfs2_super_lock() is unneeded.
--- a/fs/ocfs2/dlmglue.c
+++ b/fs/ocfs2/dlmglue.c
@@ -2544,11 +2544,6 @@ int ocfs2_super_lock(struct ocfs2_super *osb,
* refreshed, so we do it here. Of course, making sense of
* everything is up to the caller :) */
status = ocfs2_should_refresh_lock_res(lockres);
- if (status 0) {
- ocfs2_cluster_unlock(osb, lockres, level);
- mlog_errno(status);
- goto bail;
- }
if (status) {
status = ocfs2_refresh_slot_info(osb);
One does wonder if this is the correct fix. Perhaps
ocfs2_should_refresh_lock_res() should be checking something but forgot
to do so?
___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel
