<div dir="ltr">I am trying on 32 Bit micro board with ubifs file system with Linux Kernel 4.1. <div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 23, 2018 at 6:48 PM,  <span dir="ltr"><<a href="mailto:valdis.kletnieks@vt.edu" target="_blank">valdis.kletnieks@vt.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, 23 Feb 2018 15:13:30 +0530, techi eth said:<br>
<br>
> Which Linux kernel version have Year 2038 problem solved for Linux running<br>
> on 32 Bit system.<br>
><br>
> <a href="https://en.wikipedia.org/wiki/Year_2038_problem" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/<wbr>Year_2038_problem</a><br>
<br>
</span>Did you read references 15 through 17 on that page?<br>
<br>
Also, the answer isn't a strict "Linux v5.91 fixes it" - the problem wasn't fixed in<br>
one commit.  So for instance, some filesystems had 64 bit timestamps from<br>
the very beginning, while there's probably at least one or two that still need work.<br>
<br>
And if your problem is that you've got some ancient ext2 file system images that<br>
you have to keep around for forensic reasons, no kernel version is going to help<br>
(And yes, that could happen - as part of my job, I've had to keep disk images around<br>
for close to a decade due to ongoing legal action, and I've got users who need to<br>
keep research data for 30 years due to grant restrictions).<br>
<br>
So the *real* question here is - what data/hardware/whatever are you looking at<br>
where the 2038 problem is possibly relevant?<br>
</blockquote></div><br></div>