> On Sep 4, 2019, at 5:58 AM, Theodore Y. Ts'o wrote:
>
>> On Tue, Sep 03, 2019 at 09:50:09PM -0700, Deepa Dinamani wrote:
>> If we don't care to warn about the timestamps that are clamped in
>> memory, maybe we could just warn when they are being written out.
>> Would something like this be more
Am 04.09.19 um 14:58 schrieb Theodore Y. Ts'o:
> Again, the likelihood that there will be file systems that have this
> problem in 2038 is... extremely low in my judgement. Storage media
> just doesn't last that long
in times of virtualization storage media are below the vdisk and the
file sys
On Tue, Sep 03, 2019 at 09:50:09PM -0700, Deepa Dinamani wrote:
> If we don't care to warn about the timestamps that are clamped in
> memory, maybe we could just warn when they are being written out.
> Would something like this be more acceptable? I would also remove the
> warning in ext4.h. I thin
If we don't care to warn about the timestamps that are clamped in
memory, maybe we could just warn when they are being written out.
Would something like this be more acceptable? I would also remove the
warning in ext4.h. I think we don't have to check if the inode is 128
bytes here (Please correct
On Tue, Sep 03, 2019 at 03:47:54PM -0700, Deepa Dinamani wrote:
> > > diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> > > index 9e3ae3be3de9..5a971d1b6d5e 100644
> > > --- a/fs/ext4/ext4.h
> > > +++ b/fs/ext4/ext4.h
> > > @@ -835,7 +835,9 @@ do {
> > > \
> > >
> > diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> > index 9e3ae3be3de9..5a971d1b6d5e 100644
> > --- a/fs/ext4/ext4.h
> > +++ b/fs/ext4/ext4.h
> > @@ -835,7 +835,9 @@ do {
> > \
> > }
> > \
> > else{\
> > (raw_ino
On Tue, Sep 03, 2019 at 11:48:14PM +0200, Arnd Bergmann wrote:
> I think the warning as it was intended makes sense, the idea
> was never to warn on every inode update for file systems that
> cannot handle future dates, only to warn when we
>
> a) try to set a future date
> b) fail to do that beca
On Tue, Sep 03, 2019 at 02:31:06PM -0700, Deepa Dinamani wrote:
> > We need to drop this commit (ext4: Initialize timestamps limits), or
> > at least the portion which adds the call to the EXT4_INODE_SET_XTIME
> > macro in ext4.h.
>
> As Arnd said, I think this can be fixed by warning only when th
Am 03.09.19 um 23:17 schrieb Theodore Y. Ts'o:
> I know of a truly vast number of servers in production all over the
> world which are using 128 byte inodes, and spamming the inodes at the
> maximum rate limit is a really bad idea. This includes at some major
> cloud data centers where the life
On Tue, Sep 3, 2019 at 11:31 PM Deepa Dinamani wrote:
> On Tue, Sep 3, 2019 at 2:18 PM Theodore Y. Ts'o wrote:
> > On Tue, Sep 03, 2019 at 09:18:44AM -0700, Deepa Dinamani wrote:
> > >
> > > This prints a warning for each inode that doesn't extend limits beyond
> > > 2038. It is rate limited by t
On Tue, Sep 3, 2019 at 2:18 PM Theodore Y. Ts'o wrote:
>
> On Tue, Sep 03, 2019 at 09:18:44AM -0700, Deepa Dinamani wrote:
> >
> > This prints a warning for each inode that doesn't extend limits beyond
> > 2038. It is rate limited by the ext4_warning_inode().
> > Looks like your filesystem has ino
On Tue, Sep 03, 2019 at 09:18:44AM -0700, Deepa Dinamani wrote:
>
> This prints a warning for each inode that doesn't extend limits beyond
> 2038. It is rate limited by the ext4_warning_inode().
> Looks like your filesystem has inodes that cannot be extended.
> We could use a different rate limit
On Tue, 2019-09-03 at 21:50 +0200, Arnd Bergmann wrote:
> On Tue, Sep 3, 2019 at 9:39 PM Andreas Dilger wrote:
> >
> > On Sep 3, 2019, at 12:15 PM, Qian Cai wrote:
> > >
> > > On Tue, 2019-09-03 at 09:36 -0700, Deepa Dinamani wrote:
> > > > We might also want to consider updating the file syste
On Tue, Sep 3, 2019 at 9:39 PM Andreas Dilger wrote:
>
> On Sep 3, 2019, at 12:15 PM, Qian Cai wrote:
> >
> > On Tue, 2019-09-03 at 09:36 -0700, Deepa Dinamani wrote:
> >> We might also want to consider updating the file system the LTP is
> >> being run on here.
> >
> > It simply format (mkfs.ext
On Sep 3, 2019, at 12:15 PM, Qian Cai wrote:
>
> On Tue, 2019-09-03 at 09:36 -0700, Deepa Dinamani wrote:
>> We might also want to consider updating the file system the LTP is
>> being run on here.
>
> It simply format (mkfs.ext4) a loop back device on ext4 with the kernel.
>
> CONFIG_EXT4_FS=m
On Tue, 2019-09-03 at 09:36 -0700, Deepa Dinamani wrote:
> We might also want to consider updating the file system the LTP is
> being run on here.
It simply format (mkfs.ext4) a loop back device on ext4 with the kernel.
CONFIG_EXT4_FS=m
# CONFIG_EXT4_USE_FOR_EXT2 is not set
# CONFIG_EXT4_FS_POSIX
We might also want to consider updating the file system the LTP is
being run on here.
-Deepa
Actually this warning is coming from this patch:
https://lore.kernel.org/linux-fsdevel/20190818165817.32634-10-deepa.ker...@gmail.com/
([PATCH v8 09/20] ext4: Initialize timestamps limits).
This is the code generating the warning:
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 9c7f4036021b.
https://lore.kernel.org/linux-fsdevel/20190818165817.32634-5-deepa.kernel@gmail.
com/
Running only a subset of the LTP testsuite on today's linux-next with the above
commit is now generating ~800 warnings on this machine which seems a bit crazy.
[ 2130.970782] EXT4-fs warning (device loop0): ext4
19 matches
Mail list logo
