From: "Stephen Elliott" <techweb@ntlworld.com>
To: "'Bernd Schubert'" <bernd.schubert@itwm.fraunhofer.de>,
"'Andreas Dilger'" <adilger@dilger.ca>
Cc: "'Zheng Liu'" <gnehzuil.liu@gmail.com>,
"'David Jeffery'" <djeffery@redhat.com>,
<linux-ext4@vger.kernel.org>,
"'Eric Whitney'" <enwlinux@gmail.com>
Subject: RE: Query FSCK Errors on ext4
Date: Wed, 20 Nov 2013 12:46:53 -0000 [thread overview]
Message-ID: <000d01cee5ee$96eb8e40$c4c2aac0$@ntlworld.com> (raw)
In-Reply-To: <528CAC89.1040405@itwm.fraunhofer.de>
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:bernd.schubert@itwm.fraunhofer.de]
Sent: 20 November 2013 12:35
To: Stephen Elliott; 'Andreas Dilger'
Cc: 'Zheng Liu'; 'David Jeffery'; linux-ext4@vger.kernel.org; '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
prev parent reply other threads:[~2013-11-20 12:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <008701cecc19$14734370$3d59ca50$@ntlworld.com>
2013-10-28 6:13 ` Query FSCK Errors on ext4 Andreas Dilger
2013-10-28 6:39 ` Zheng Liu
2013-10-28 9:00 ` Stephen Elliott
2013-10-28 20:53 ` Andreas Dilger
2013-10-28 21:18 ` Stephen Elliott
2013-11-19 12:44 ` Stephen Elliott
2013-11-19 16:46 ` Andreas Dilger
2013-11-19 17:35 ` Stephen Elliott
2013-11-19 20:27 ` Andreas Dilger
2013-11-19 20:48 ` Stephen Elliott
[not found] ` <C8263588-E5AD-4C23-81E3-5852DE3B1FC5@dilger.ca>
[not found] ` <002e01cee56f$46f8e3d0$d4eaab70$@ntlworld.com>
2013-11-20 12:35 ` Bernd Schubert
2013-11-20 12:46 ` Stephen Elliott [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000d01cee5ee$96eb8e40$c4c2aac0$@ntlworld.com' \
--to=techweb@ntlworld.com \
--cc=adilger@dilger.ca \
--cc=bernd.schubert@itwm.fraunhofer.de \
--cc=djeffery@redhat.com \
--cc=enwlinux@gmail.com \
--cc=gnehzuil.liu@gmail.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).