headers
Bas van Schaik | 2 Mar 2008 20:08
Picon

Re: e2fsck dies with error "this should never happen!!!"

Theodore Tso wrote:
> On Fri, Feb 22, 2008 at 08:31:13PM +0100, Bas van Schaik wrote:
>   
>>> Yeah, it could be quite big, given that you have a 3TB filesystem.  That's
>>> why I suggested the "or given me login access to the system", although
>>> understand there could be all sorts of privacy and security issues
>>> involved with that request.
>>>       
>> The dump is not ready yet...
>>
>> Whatever we will do, it will have to wait for a week and a half. For now I
>> really appreciate all the help.
>>     
> Ok, when you get back, I should also have a patch for you that will
> allow the "XXX should never happen" message to display more
> information, so if the dump is too big for us to move over the
> network, I'll have another way of doing some remote debugging.
>   
Last night I returned from my holiday trip, so I'm available again. The
e2image dump completed somewhere during my absence and has grown to 1.6
gigabytes (bzip2), too large to actually publish if you ask me. I think
it is okay to provide you access to the system, please contact me
(preferably using a GPG-encrypted message) so we can agree on the
details. Of course it would be great if you can send a patch which will
make e2fsck more verbose.

  -- Bas
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply |
headers
Bas van Schaik | 7 Mar 2008 14:41
Picon

Re: e2fsck dies with error "this should never happen!!!"

Bas van Schaik wrote:
> Theodore Tso wrote:
>   
>> On Fri, Feb 22, 2008 at 08:31:13PM +0100, Bas van Schaik wrote:
>>   
>>     
>>>> Yeah, it could be quite big, given that you have a 3TB filesystem.  That's
>>>> why I suggested the "or given me login access to the system", although
>>>> understand there could be all sorts of privacy and security issues
>>>> involved with that request.
>>>>       
>>>>         
>>> The dump is not ready yet...
>>>
>>> Whatever we will do, it will have to wait for a week and a half. For now I
>>> really appreciate all the help.
>>>     
>>>       
>> Ok, when you get back, I should also have a patch for you that will
>> allow the "XXX should never happen" message to display more
>> information, so if the dump is too big for us to move over the
>> network, I'll have another way of doing some remote debugging.
>>   
>>     
> Last night I returned from my holiday trip, so I'm available again. The
> e2image dump completed somewhere during my absence and has grown to 1.6
> gigabytes (bzip2), too large to actually publish if you ask me. I think
> it is okay to provide you access to the system, please contact me
> (preferably using a GPG-encrypted message) so we can agree on the
> details. Of course it would be great if you can send a patch which will
(Continue reading)

Permalink | Reply |
headers
Eric Sandeen | 7 Mar 2008 16:50
Picon
Favicon
Gravatar

Re: e2fsck dies with error "this should never happen!!!"

Bas van Schaik wrote:

> Why is e2image refusing to restore the metadata, and what does "File too
> large" mean?

How big are things really?  stracing the command would show you what is
returning the error...

-Eric

> I think this is pretty much the moment were I can say "HELP!!!"
> 
>   -- Bas

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply |
headers
Bas van Schaik | 7 Mar 2008 17:29
Picon

Re: e2fsck dies with error "this should never happen!!!"

Eric Sandeen wrote:
> Bas van Schaik wrote:
>
>   
>> Why is e2image refusing to restore the metadata, and what does "File too
>> large" mean?
>>     
> How big are things really?  stracing the command would show you what is
> returning the error...
>   
The image file is 35335922 kbytes (= about 33GB), but is of course
sparse and actually uses 4218560 kbytes (= about 4 GB). The original
filesystem is 550502400 blocks long (block size 4096, number of inodes:
275251200).

The last few lines of output when using strace:
> close(4)                                = 0
> open("/usr/lib/gconv/ISO8859-1.so", O_RDONLY) = 4
> read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\4\0"...,
> 512) = 512
> fstat64(4, {st_mode=S_IFREG|0644, st_size=9436, ...}) = 0
> mmap2(NULL, 8228, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4,
> 0) = 0xb1ab3000
> mmap2(0xb1ab4000, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1) = 0xb1ab4000
> close(4)                                = 0
> write(2, "e2image-pre-e2fsck-snapshot_2008"...,
> 55e2image-pre-e2fsck-snapshot_2008-03-06: File too large
> ) = 55
> exit_group(1)                           = ?
(Continue reading)

Permalink | Reply |
headers
Theodore Tso | 7 Mar 2008 18:45
Picon
Picon
Favicon

Re: e2fsck dies with error "this should never happen!!!"

Can you send me the full strace output?

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply |
headers
Bas van Schaik | 7 Mar 2008 19:12
Picon

Re: e2fsck dies with error "this should never happen!!!"

Theodore Tso wrote:
> Can you send me the full strace output?
>
> 						- Ted
>   
Sure (and indeed, it contains some EFBIG output):
> # strace e2image -I /dev/loop2 e2image-pre-e2fsck-snapshot_2008-03-06
> execve("/sbin/e2image", ["e2image", "-I", "/dev/loop2",
> "e2image-pre-e2fsck-snapshot_2008"...], [/* 19 vars */]) = 0
> uname({sys="Linux", node="infinity", ...}) = 0
> brk(0)                                  = 0x804c000
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7eed000
> access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or
> directory)
> open("/etc/ld.so.cache", O_RDONLY)      = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=20396, ...}) = 0
> mmap2(NULL, 20396, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ee8000
> close(3)                                = 0
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> open("/lib/libext2fs.so.2", O_RDONLY)   = 3
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320N\0"...,
> 512) = 512
> fstat64(3, {st_mode=S_IFREG|0644, st_size=102892, ...}) = 0
> mmap2(NULL, 105844, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
> 0) = 0xb7ece000
> mmap2(0xb7ee7000, 4096, PROT_READ|PROT_WRITE,
(Continue reading)

Permalink | Reply |

Gmane