Bodo Thiesen
2014-Jun-02 21:04 UTC
Re: [long] major problems on fs; e2fsck running out of memory
* "Theodore Ts'o" <tytso@mit.edu> hat geschrieben: Hi Theodore.> That being said, it's pretty clear that portions of the inode table > and block group descriptor was badly corrupted. [...]Keith is not the first one with problems of this class and he will probably not be the last one. He later told us, that at first, mounting the file system still worked. And that acually means (taking low level software errors or hardware errors out of the equation), that actually e2fsck created the current situation. In my opinion, e2fsck has one major flaw actually causing this sort of troubles: e2fsck tries to fix the errors as it actually finds them. That's bad, because at that point it's still unclear, whether the problem can be safely fixed yet. So, the thing e2fsck SHOULD do is: 1. Scan the file system for all errors, remember the errors BUT DON'T TOUCH ANYTHING. 2. Once all errors (including differences in allocation bitmaps) have been collected, it should then first summarize the bugs (like: 100 times checksum errors, 56000 times illegal pointers etc) and then ask, what to do. 3. Actually fix the errors one-by-one taking into account calculated allocation bitmaps (instead of the ones stored in the file system). Some errors have to be fixed before other ones, resolving multiple used clusters being the first kind of errors to be fixed). This would not only allow the user to cancel at this point with no changes to the file system being done yet, it would also allow e2fsck to make sure, that newly allocated clusters will always go to clusters, which are actually not in use. What do you think about this? Regards, Bodo
Keith Keller
2014-Jun-02 21:27 UTC
Re: [long] major problems on fs; e2fsck running out of memory
Hi all, On Mon, Jun 02, 2014 at 11:04:52PM +0200, Bodo Thiesen wrote:> > Keith is not the first one with problems of this class and he will > probably not be the last one. He later told us, that at first, mounting > the file system still worked.Is there any value in discussing this issue in keeping this broken filesystem available for debugging purposes? I would like at this point to destroy the filesystem and start my restores, but if it'd be helpful to try to get information from the existing fs I can keep it around a while longer. (I do still have whatever fsck logs that I saved, and can make them available whether I destroy the fs or not.) --keith -- kkeller@wombat.san-francisco.ca.us
Bodo Thiesen
2014-Jun-07 19:03 UTC
Re: [long] major problems on fs; e2fsck running out of memory
* Keith Keller <kkeller@wombat.san-francisco.ca.us> hat geschrieben:> Is there any value in discussing this issue in keeping this broken > filesystem available for debugging purposes?I don't believe so. I have my own broken fs here (totally different story - and I knew, I couldn't trust neither the kernel nor e2fsck - so I used dm-cow for all testing).> I would like at this point > to destroy the filesystem and start my restores, but if it'd be helpful > to try to get information from the existing fs I can keep it around a > while longer. (I do still have whatever fsck logs that I saved, and can > make them available whether I destroy the fs or not.)If you want to keep the important fs structures, run e2image. No need to keep the entire file system. But since Ted didn't respond, I assume, there is no need to do even that. Regards, Bodo
Seemingly Similar Threads
- Re: [long] major problems on fs; e2fsck running out of memory
- Re: [long] major problems on fs; e2fsck running out of memory
- Re: [long] major problems on fs; e2fsck running out of memory
- Re: [long] major problems on fs; e2fsck running out of memory
- [long] major problems on fs; e2fsck running out of memory