Hello Stephen,
can you reproduce this on a fresh filesystem and on a system that you
can easily update? If you can, can you update the kernel to a
stable/recent version (i.e. longterm 3.10) and e2fsprogs to a current
version, re-create a fresh file system and try to reproduce again? If
you still can, can you try to figure out which order of syscalls is
causing the corruption? Or anything else that might help to figure out
the root cause?
In general, using a rather old kernel and user space tools and pointing
to an issue isn't going to help you much.
Cheers,
Bernd
Hi Bernd,
Appreciate the follow up... My issue with the ReadyNAS appliance is I don't have control of what releases etc they use.
At some point in the future, if I have a system where I can carry out this testing then I will. However, from my side this really isn't a problem, now I know about it. I came to this forum out of curiosity and wanting to ensure that there isn't a whole in the Linux Kernel / e2fsprogs which you guys would be passionate about fixing.
>From a developers perspective I imagine a simple attempt to reproduce this would be fairly simplistic and would probably be no more than an evening's work. Basically having multiple connections to a substantial MS Access DB from clients over SMB and then reloading the server. Although agree there is little point in fixing an old Kernel.
I guess we can close this discussion point now.
Many Thanks
Stephen Elliott
-----Original Message-----
From: Bernd Schubert [mailto:[email protected]]
Sent: 20 November 2013 12:35
To: Stephen Elliott; 'Andreas Dilger'
Cc: 'Zheng Liu'; 'David Jeffery'; [email protected]; 'Eric Whitney'
Subject: Re: Query FSCK Errors on ext4
Hello Stephen,
can you reproduce this on a fresh filesystem and on a system that you can easily update? If you can, can you update the kernel to a stable/recent version (i.e. longterm 3.10) and e2fsprogs to a current version, re-create a fresh file system and try to reproduce again? If you still can, can you try to figure out which order of syscalls is causing the corruption? Or anything else that might help to figure out the root cause?
In general, using a rather old kernel and user space tools and pointing to an issue isn't going to help you much.
Cheers,
Bernd