Bug with future timestamp

Bug with future timestamp

[Michele Marcon]

Hi,
I'm using nilfs on ARM I have found a problem when these conditions are met:

- set protection period to 60 seconds
- set current time on the future (example: year 2020)
- write something on flash, so that some checkpoints are created
- set current time to the present
- perform writes on flash.

When the garbage collector starts, it will notice that the checkpoint "from the future" is protected and will not remove it.
The problem is that it will not remove subsequent checkpoints (but with timestamp that shouldn't be protected), and therefore there won't be any garbage collection until 2020.

The only workaround is to manually remove the "future" checkpoints with rmcp.

Is this a known issue? Thanks!



Michele Marcon

Centro Ricerche
RPS SpA
Viale Europa, 7
37045 Legnago VR
Tel. +39 0442 635939 Fax. +39 0442 635934
Skype Id:  - Voip: 
E-mail: M.Marcon-wB/b/6WKJkjDzftRWevZcw@public.gmane.org
Web: www.riello-ups.com
--------------------------------------------------------------------------
Per favore non stampare questo messaggio se proprio non è 
necessario 
Please consider the environment before printing this e-mail
--------------------------------------------------------------------------




--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug with future timestamp

[Jérôme Poulin]

On Tue, Jun 14, 2016 at 10:54 AM, Michele Marcon
<M.Marcon-wB/b/6WKJkjDzftRWevZcw@public.gmane.org> wrote:
> When the garbage collector starts, it will notice that the checkpoint "from the future" is protected and will not remove it.
> The problem is that it will not remove subsequent checkpoints (but with timestamp that shouldn't be protected), and therefore there won't be any garbage collection until 2020.
>
> The only workaround is to manually remove the "future" checkpoints with rmcp.
>
> Is this a known issue? Thanks!


I was bit by the opposite problem on my day to day laptop. I set my
time in the past for some hours, then after restoring the correct
time, the garbage collector destroyed all the checkpoints from the
past. At this point, the FS was screwed. I reported the issue and
can't find the patch that fixed it but I guess this is the kind of
protection to be expected from my issue, checkpoints from the future
can't be cleaned up.

Pseudo-References:
http://www.spinics.net/lists/linux-nilfs/msg00592.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug with future timestamp

[Ryusuke Konishi]

Hi,
On Tue, 14 Jun 2016 14:54:26 +0000, Michele Marcon wrote:
> Hi,
> I'm using nilfs on ARM I have found a problem when these conditions are met:
> 
> - set protection period to 60 seconds
> - set current time on the future (example: year 2020)
> - write something on flash, so that some checkpoints are created
> - set current time to the present
> - perform writes on flash.
> 
> When the garbage collector starts, it will notice that the
> checkpoint "from the future" is protected and will not remove it.
> The problem is that it will not remove subsequent checkpoints (but
> with timestamp that shouldn't be protected), and therefore there
> won't be any garbage collection until 2020.

Does this state really continue even if you continue writing after the
rewind ?

Checkpoint is protected not only by the protection period but also by
a few other conditions, for instance, recent segments are "active" and
protected from GC.  (the data and checkpoints in the active segments
may be protected regardless of their timestamps).  You can confirm if
the segment is active or not through the 'a' flag of lssu command.
  
If every block which belongs to a checkpoint is protected by GC,
then the checkpoint will not be discarded even if it has a timestamp
that can be removed.

> 
> The only workaround is to manually remove the "future" checkpoints
> with rmcp.
> 

rmcp in reality doesn't help to reclaim blocks.  It only invalidates
checkpoints and makes them unaccessible.

Regards,
Ryusuke Konishi


> Is this a known issue? Thanks!
> 
> 
> 
> Michele Marcon
> 
> Centro Ricerche
> RPS SpA
> Viale Europa, 7
> 37045 Legnago VR
> Tel. +39 0442 635939 Fax. +39 0442 635934
> Skype Id:  - Voip: 
> E-mail: M.Marcon-wB/b/6WKJkjDzftRWevZcw@public.gmane.org
> Web: www.riello-ups.com
> --------------------------------------------------------------------------
> Per favore non stampare questo messaggio se proprio non è 
> necessario 
> Please consider the environment before printing this e-mail
> --------------------------------------------------------------------------
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug with future timestamp

[Ryusuke Konishi]

Hi,
On Tue, 14 Jun 2016 20:54:32 -0400, Jérôme Poulin wrote:
> On Tue, Jun 14, 2016 at 10:54 AM, Michele Marcon
> <M.Marcon-wB/b/6WKJkjDzftRWevZcw@public.gmane.org> wrote:
>> When the garbage collector starts, it will notice that the checkpoint "from the future" is protected and will not remove it.
>> The problem is that it will not remove subsequent checkpoints (but with timestamp that shouldn't be protected), and therefore there won't be any garbage collection until 2020.
>>
>> The only workaround is to manually remove the "future" checkpoints with rmcp.
>>
>> Is this a known issue? Thanks!
> 
> 
> I was bit by the opposite problem on my day to day laptop. I set my
> time in the past for some hours, then after restoring the correct
> time, the garbage collector destroyed all the checkpoints from the
> past. At this point, the FS was screwed. I reported the issue and
> can't find the patch that fixed it but I guess this is the kind of
> protection to be expected from my issue, checkpoints from the future
> can't be cleaned up.
> 
> Pseudo-References:
> http://www.spinics.net/lists/linux-nilfs/msg00592.html

Do you mean an fs curruption occurs (even now) after the above rewinding ?

If you mean all checkpoints looks to be removed, could you try "-a"
option of the lscp command ?

Regards,
Ryusuke Konishi

> --
> To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bug with future timestamp

[Michele Marcon]

Yes, the state continues until the system become unusable.
No, these fragments aren't active.

This is the log of the commands issued and the results:

http://pastebin.com/jf6C5SST

Thanks.

-----Messaggio originale-----
Da: Ryusuke Konishi [mailto:konishi.ryusuke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] Per conto di Ryusuke Konishi
Inviato: mercoledì 15 giugno 2016 17:03
A: Michele Marcon <M.Marcon-wB/b/6WKJkjDzftRWevZcw@public.gmane.org>
Cc: linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Oggetto: Re: Bug with future timestamp

Hi,
On Tue, 14 Jun 2016 14:54:26 +0000, Michele Marcon wrote:
> Hi,
> I'm using nilfs on ARM I have found a problem when these conditions are met:
> 
> - set protection period to 60 seconds
> - set current time on the future (example: year 2020)
> - write something on flash, so that some checkpoints are created
> - set current time to the present
> - perform writes on flash.
> 
> When the garbage collector starts, it will notice that the checkpoint 
> "from the future" is protected and will not remove it.
> The problem is that it will not remove subsequent checkpoints (but 
> with timestamp that shouldn't be protected), and therefore there won't 
> be any garbage collection until 2020.

Does this state really continue even if you continue writing after the rewind ?

Checkpoint is protected not only by the protection period but also by a few other conditions, for instance, recent segments are "active" and protected from GC.  (the data and checkpoints in the active segments may be protected regardless of their timestamps).  You can confirm if the segment is active or not through the 'a' flag of lssu command.
  
If every block which belongs to a checkpoint is protected by GC, then the checkpoint will not be discarded even if it has a timestamp that can be removed.

> 
> The only workaround is to manually remove the "future" checkpoints 
> with rmcp.
> 

rmcp in reality doesn't help to reclaim blocks.  It only invalidates checkpoints and makes them unaccessible.

Regards,
Ryusuke Konishi


> Is this a known issue? Thanks!
> 
> 
> 
> Michele Marcon
> 
> Centro Ricerche
> RPS SpA
> Viale Europa, 7
> 37045 Legnago VR
> Tel. +39 0442 635939 Fax. +39 0442 635934 Skype Id:  - Voip:
> E-mail: M.Marcon-wB/b/6WKJkjDzftRWevZcw@public.gmane.org
> Web: 
> https://emea01.safelinks.protection.outlook.com/?url=www.riello-ups.co
> m&data=01%7c01%7cM.Marcon%40riello-ups.com%7c9bd83d76a4a74e5957cc08d39
> 52e3523%7cd8fd0d398b2f4760af9e84aadb8587ef%7c0&sdata=epS8f0YmqRj5iG%2f
> xh27hngehxiqYPYKHpsq5EPFnRxI%3d
> ----------------------------------------------------------------------
> ---- Per favore non stampare questo messaggio se proprio non è 
> necessario Please consider the environment before printing this e-mail
> ----------------------------------------------------------------------
> ----
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nilfs" 
> in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo 
> info at 
> https://emea01.safelinks.protection.outlook.com/?url=http%3a%2f%2fvger
> .kernel.org%2fmajordomo-info.html&data=01%7c01%7cM.Marcon%40riello-ups
> .com%7c9bd83d76a4a74e5957cc08d3952e3523%7cd8fd0d398b2f4760af9e84aadb85
> 87ef%7c0&sdata=ZPLbeEsIU%2fXq%2bXhA5LyU5jBEUUO31zLeLbIa8kijIK4%3d
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html