[Bug 218006] [ext4] system panic when ext4_writepages:2918: Journal has aborted

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.kernel.org/show_bug.cgi?id=218006

--- Comment #7 from Gary (fengchunguo@xxxxxxx) ---
(In reply to Theodore Tso from comment #6)
> Unfortunately the 4.14 kernel was released in 2017, which is over six years
> ago.   Most companies where you can pay $$$ to get support for Linux
> distributions based on 4.14 are EOL'ing products based on 4.14.   As far
> upstream kernel developers who are essentially volunteers when people ask
> them for free help, in general, upstream kernel developers do not support
> LTS kernels, and certainly not an LTS kernel as old as 4.14.
> 
> If there is someone is willing to be the ext4 upstream stable backports
> maintainer, then that person might be willing to provide limited support for
> LTS kernels --- but the 4.14 LTS upstream kernel is planned to be EOL'ed in
> January 2024, and I had stopped running gce-xfstests on 4.14 LTS kernels
> about a year or so ago.  I barely have time to run gce-xfststs on LTS
> kernels for 6.1, 5.15 and 5.10 every quarter or two, and if someone were to
> volunteer to become ext4 stable backports maintainer, I'd encourage them to
> focus on 6.6 and 6.1 LTS kernels, with 5.10 and 5.15 LTS kernels as a lower
> priority (because most commercial companies are going to be moving off of
> 5.10 LTS in the near future).   But volunteer support for 4.14 LTS?  TO be
> honest, that's extremely unlikely.
> 
> *If* there is a company that has a misguided business reason to support the
> 4.14 LTS kernel, then of course an employee of that company can certainly
> fund an engineer to to do all of the support that they need.  But quite
> frankly, I'd be encouraging that company to rethink their business case for
> supporting the 4.14 kernel.   It would be probably far more cost effective
> to migrate their customers to a non-pre-historic kernel such as the 6.6 LTS
> kernel.

Thanks for your reply.

We will try to debug this issue. For this issue, I think that we should focus
on the below infromation. Emmc error should be one side effect.

[2023-10-13 02:51:08]  [60086.731357] EXT4-fs error (device mmcblk0p44) in
ext4_da_write_end:3210: IO failure
[2023-10-13 02:51:09]  [60086.739386] EXT4-fs (mmcblk0p44): Delayed block
allocation failed for inode 155757 at logical offset 438 with max blocks 25
with error 30
[2023-10-13 02:51:09]  [60086.739388] EXT4-fs (mmcblk0p44): This should not
happen!! Data will be lost
[2023-10-13 02:51:09]  [60086.739388]
[2023-10-13 02:51:09]  [60086.739399] EXT4-fs error (device mmcblk0p44) in
ext4_writepages:2918: Journal has aborted

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.



[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux