The VFS inode timestamps are not y2038 safe as they use
struct timespec. These will be changed to use struct timespec64
instead and that is y2038 safe.
But, since the above data type conversion will break the end
file systems, use vfs_time aliases here to access inode times.
These timestamps are
The VFS inode timestamps are not y2038 safe as they use
struct timespec. These will be changed to use struct timespec64
instead and that is y2038 safe.
But, since the above data type conversion will break the end
file systems, use vfs_time aliases here to access inode times.
Use vfs_time data
The VFS inode timestamps are not y2038 safe as they use
struct timespec. These will be changed to use struct timespec64
instead and that is y2038 safe.
But, since the above data type conversion will break the end
file systems, use vfs_time aliases here to access inode times.
This is set as a vfs
The VFS inode timestamps are not y2038 safe as they use
struct timespec. These will be changed to use struct timespec64
instead and that is y2038 safe.
But, since the above data type conversion will break the end
file systems, use vfs_time aliases here to access inode times.
The following needs to
The VFS inode timestamps are not y2038 safe as they use
struct timespec. These will be changed to use struct timespec64
instead and that is y2038 safe.
But, since the above data type conversion will break the end
file systems, use vfs_time aliases here to access inode times.
vfs_time is an
Add vfs_time accessors to help convert vfs timestamps to use
64 bit times. These create an abstraction layer so that
vfs inode times can be switched to struct timespec64 from
struct timespec without breaking the individual filesystems
after they have incorporated these.
Add vfs_time data type
The VFS inode timestamps are not y2038 safe as they use
struct timespec. These will be changed to use struct timespec64
instead and that is y2038 safe.
But, since the above data type conversion will break the end
file systems, use vfs_time aliases here to access inode times.
aux data timestamps
Introduction
The series is one of the proposals on how to transition VFS timestamps
to use 64 bit time. This is the inode_timespec idea proposed in the
original RFC series. The type name has been changed to vfs_time based
on Dave Chinner’s suggestion.
Solution
This series defines a new type
Introduction
This is a follow on to the series: https://lkml.org/lkml/2016/1/7/20 [1].
This is aimed at reaching a consensus on how to transition the vfs
timestamps to use 64 bit time. This demonstrates three ways (2a, 2b and
2c) of solving this problem. Each of the proposals has its own cover
The VFS inode timestamps are not y2038 safe as they use
struct timespec. These will be changed to use struct timespec64
instead and that is y2038 safe.
But, since the above data type conversion will break the end
file systems, use timespec64 and conversion functions here to
access inode times.
The VFS inode timestamps are not y2038 safe as they use
struct timespec. These will be changed to use struct timespec64
instead and that is y2038 safe.
But, since the above data type conversion will break the end
file systems, use timespec64 and conversion functions here to
access inode times.
The VFS inode timestamps are not y2038 safe as they use
struct timespec. These will be changed to use struct timespec64
instead and that is y2038 safe.
But, since the above data type conversion will break the end
file systems, use timespec64 and conversion functions here to
access inode times.
Aux data timestamps are only used to read in inode timestamps for
fscache.
The VFS inode timestamps are not y2038 safe as they use struct timespec.
These will be changed to use struct timespec64 instead and that is y2038
safe. But, since the above data type conversion will break the end file
The seconds calculated from the server(DOS format)
cannot be saved in int data type as this cannot save
seconds since epoch after the year 2038.
Use long long for seconds field in cnvrtDosUnixTm(). This will
help represent 64 bit time even on 32 bit systems.
Note that even though the theoretical
On Friday 12 February 2016 01:21:59 Deepa Dinamani wrote:
> Introduction
>
> This is a follow on to the series: https://lkml.org/lkml/2016/1/7/20 [1].
> This is aimed at reaching a consensus on how to transition the vfs
> timestamps to use 64 bit time. This demonstrates three ways (2a, 2b and
>
On Friday 12 February 2016 01:45:47 Deepa Dinamani wrote:
> + ts = vfs_time_to_timespec(inode->i_mtime);
> + if (!timespec_equal(, ))
> + inode->i_mtime = timespec_to_vfs_time(now);
> +
> + ts = vfs_time_to_timespec(inode->i_mtime);
> + if (!timespec_equal(,
The VFS inode timestamps are not y2038 safe as they use
struct timespec. These will be changed to use struct timespec64
instead and that is y2038 safe.
But, since the above data type conversion will break the end
file systems, use timespec64 and conversion functions here to
access inode times.
> Regarding the three versions, I think all of them are doable
> doable, and they all have their upsides and downsides but no
> showstoppers.
I agree that all the approaches are doable.
> Let me summarize what I see in the patches:
>
> 2a is the smallest set of changes in number of lines, as you
18 matches
Mail list logo
