* fsck.reiser4 mishandling large files
@ 2010-04-11 3:47 Morgan Smith
2010-04-11 23:57 ` Edward Shishkin
0 siblings, 1 reply; 2+ messages in thread
From: Morgan Smith @ 2010-04-11 3:47 UTC (permalink / raw
To: reiserfs-devel
Hello,
I was trying out fsck.reiser4 on an external drive I have and it said
there were fatal corruptions detected in the file system and suggested
running again with --build-fs. Looking at the output of fsck.reiser4 I
found the inode numbers of the files that were listed and I used the
find command to track them down. All of the files that fsck.reiser4
listed were large files, 4.4GB a piece (OpenSUSE and CentOS DVD iso
files). After some testing outside of that disk, it seems as though
fsck.reiser4 will proclaim fatal corruptions if there are files
greater than 4GB in size (my iso was 4.4GB) and suggests --build-fs.
Using --build-fs corrupts the large files. Is there a plugin that I
may not have enabled to allow for the safe fscking of large files?
The error is experienced using reg40 or ccreg40. Between tests I used
dd to zero out all data on the partition before reformatting with
different options. My testing involved creating a small partition on
the drive, formatting it with reiser4, mounting it, creating a large
file on the file system (tarball of iso files), dismounting it,
running fsck.reiser4, mounting it, extracting tarball, verifying iso
images against the originals with md5sum.
With a reg40 format I get this:
Master super block (16):
magic: ReIsEr4
blksize: 4096
format: 0x0 (format40)
uuid: f3cb070c-9c88-492d-b6a2-f83025ce6eb6
label: <none>
Format super block (17):
plugin: format40
description: Disk-format plugin.
version: 0
magic: ReIsEr40FoRmAt
mkfs id: 0x38576ea3
flushes: 0
blocks: 1572864
free blocks: 92393
root block: 1034712
tail policy: 0x2 (smart)
next oid: 0x10001
file count: 2
tree height: 2
key policy: LARGE
CHECKING THE STORAGE TREE
Read nodes 2
Nodes left in the tree 2
Leaves of them 1, Twigs of them 1
Time interval: Sat Apr 10 21:12:39 2010 - Sat Apr 10 21:12:39 2010
CHECKING EXTENT REGIONS.
FSCK: extent40_repair.c: 96: extent40_check_layout: Node (1034712),
item (1), unit (80),
[2a:4(FB):6c617267652e74:10000:0]: points out of the fs, region
[1571329..1572863].
Read twigs 1
Invaid extent pointers 1
Time interval: Sat Apr 10 21:12:39 2010 - Sat Apr 10 21:12:39 2010
CHECKING THE SEMANTIC TREE
Found 2 objects (some could be encountered more then once).
Time interval: Sat Apr 10 21:12:39 2010 - Sat Apr 10 21:12:39 2010
FSCK: repair.c: 550: repair_sem_fini: On-disk used block bitmap and
really used block
bitmap differ.
***** fsck.reiser4 finished at Sat Apr 10 21:12:39 2010
Closing fs...done
1 fatal corruptions were detected in FileSystem. Run with --build-fs
option to fix them.
With ccreg40 format I get this:
Master super block (16):
magic: ReIsEr4
blksize: 4096
format: 0x0 (format40)
uuid: b916bc54-a228-467f-bd0c-9097988d3118
label: <none>
Format super block (17):
plugin: format40
description: Disk-format plugin.
version: 0
magic: ReIsEr40FoRmAt
mkfs id: 0x4551a4df
flushes: 0
blocks: 1572864
free blocks: 408714
root block: 1164381
tail policy: 0x2 (smart)
next oid: 0x10001
file count: 2
tree height: 5
key policy: LARGE
CHECKING THE STORAGE TREE
Read nodes 1164071
Nodes left in the tree 1164071
Leaves of them 1150840, Twigs of them 13078
Time interval: Sat Apr 10 19:58:04 2010 - Sat Apr 10 19:59:20 2010
CHECKING EXTENT REGIONS.
Read twigs 13078
Time interval: Sat Apr 10 19:59:20 2010 - Sat Apr 10 20:00:23 2010
CHECKING THE SEMANTIC TREE
FSCK: ccreg40_repair.c: 187: ccreg40_check_cluster: The file
[2a:6c617267652e74:10000]
(ccreg40): the cluster at [319799296] offset 8192 bytes long is corrupted.
Found 1 objects (some could be encountered more then once).
Time interval: Sat Apr 10 20:00:23 2010 - Sat Apr 10 20:01:39 2010
***** fsck.reiser4 finished at Sat Apr 10 20:01:40 2010
Closing fs...done
1 fatal corruptions were detected in FileSystem. Run with --build-fs
option to fix them.
Here is some additional information which may help:
# uname -a
Linux beefy 2.6.31-gentoo-r10 #6 SMP Tue Mar 30 18:36:29 MDT 2010
x86_64 Intel(R) Xeon(TM) CPU 3.00GHz GenuineIntel GNU/Linux
# fsck.reiser4 --version
fsck.reiser4 1.0.7
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: fsck.reiser4 mishandling large files
2010-04-11 3:47 fsck.reiser4 mishandling large files Morgan Smith
@ 2010-04-11 23:57 ` Edward Shishkin
0 siblings, 0 replies; 2+ messages in thread
From: Edward Shishkin @ 2010-04-11 23:57 UTC (permalink / raw
To: Morgan Smith; +Cc: reiserfs-devel
Hello.
Thanks a lot for your details.
It seems that some 32-bit fsck counter has overflown.
I'll take a look, as It is reproducible..
In the case of reg40 plugin the file system structure is very
simple: just 2 nodes and a single extent pointer, so I think
it won't be a big deal to catch the bug..
Edward.
Morgan Smith wrote:
> Hello,
>
> I was trying out fsck.reiser4 on an external drive I have and it said
> there were fatal corruptions detected in the file system and suggested
> running again with --build-fs. Looking at the output of fsck.reiser4 I
> found the inode numbers of the files that were listed and I used the
> find command to track them down. All of the files that fsck.reiser4
> listed were large files, 4.4GB a piece (OpenSUSE and CentOS DVD iso
> files). After some testing outside of that disk, it seems as though
> fsck.reiser4 will proclaim fatal corruptions if there are files
> greater than 4GB in size (my iso was 4.4GB) and suggests --build-fs.
> Using --build-fs corrupts the large files. Is there a plugin that I
> may not have enabled to allow for the safe fscking of large files?
>
> The error is experienced using reg40 or ccreg40. Between tests I used
> dd to zero out all data on the partition before reformatting with
> different options. My testing involved creating a small partition on
> the drive, formatting it with reiser4, mounting it, creating a large
> file on the file system (tarball of iso files), dismounting it,
> running fsck.reiser4, mounting it, extracting tarball, verifying iso
> images against the originals with md5sum.
>
> With a reg40 format I get this:
> Master super block (16):
> magic: ReIsEr4
> blksize: 4096
> format: 0x0 (format40)
> uuid: f3cb070c-9c88-492d-b6a2-f83025ce6eb6
> label: <none>
>
> Format super block (17):
> plugin: format40
> description: Disk-format plugin.
> version: 0
> magic: ReIsEr40FoRmAt
> mkfs id: 0x38576ea3
> flushes: 0
> blocks: 1572864
> free blocks: 92393
> root block: 1034712
> tail policy: 0x2 (smart)
> next oid: 0x10001
> file count: 2
> tree height: 2
> key policy: LARGE
>
>
> CHECKING THE STORAGE TREE
> Read nodes 2
> Nodes left in the tree 2
> Leaves of them 1, Twigs of them 1
> Time interval: Sat Apr 10 21:12:39 2010 - Sat Apr 10 21:12:39 2010
> CHECKING EXTENT REGIONS.
> FSCK: extent40_repair.c: 96: extent40_check_layout: Node (1034712),
> item (1), unit (80),
> [2a:4(FB):6c617267652e74:10000:0]: points out of the fs, region
> [1571329..1572863].
> Read twigs 1
> Invaid extent pointers 1
> Time interval: Sat Apr 10 21:12:39 2010 - Sat Apr 10 21:12:39 2010
> CHECKING THE SEMANTIC TREE
> Found 2 objects (some could be encountered more then once).
> Time interval: Sat Apr 10 21:12:39 2010 - Sat Apr 10 21:12:39 2010
> FSCK: repair.c: 550: repair_sem_fini: On-disk used block bitmap and
> really used block
> bitmap differ.
> ***** fsck.reiser4 finished at Sat Apr 10 21:12:39 2010
> Closing fs...done
>
> 1 fatal corruptions were detected in FileSystem. Run with --build-fs
> option to fix them.
>
>
> With ccreg40 format I get this:
> Master super block (16):
> magic: ReIsEr4
> blksize: 4096
> format: 0x0 (format40)
> uuid: b916bc54-a228-467f-bd0c-9097988d3118
> label: <none>
>
> Format super block (17):
> plugin: format40
> description: Disk-format plugin.
> version: 0
> magic: ReIsEr40FoRmAt
> mkfs id: 0x4551a4df
> flushes: 0
> blocks: 1572864
> free blocks: 408714
> root block: 1164381
> tail policy: 0x2 (smart)
> next oid: 0x10001
> file count: 2
> tree height: 5
> key policy: LARGE
>
>
> CHECKING THE STORAGE TREE
> Read nodes 1164071
> Nodes left in the tree 1164071
> Leaves of them 1150840, Twigs of them 13078
> Time interval: Sat Apr 10 19:58:04 2010 - Sat Apr 10 19:59:20 2010
> CHECKING EXTENT REGIONS.
> Read twigs 13078
> Time interval: Sat Apr 10 19:59:20 2010 - Sat Apr 10 20:00:23 2010
> CHECKING THE SEMANTIC TREE
> FSCK: ccreg40_repair.c: 187: ccreg40_check_cluster: The file
> [2a:6c617267652e74:10000]
> (ccreg40): the cluster at [319799296] offset 8192 bytes long is corrupted.
> Found 1 objects (some could be encountered more then once).
> Time interval: Sat Apr 10 20:00:23 2010 - Sat Apr 10 20:01:39 2010
> ***** fsck.reiser4 finished at Sat Apr 10 20:01:40 2010
> Closing fs...done
>
> 1 fatal corruptions were detected in FileSystem. Run with --build-fs
> option to fix them.
>
>
> Here is some additional information which may help:
>
> # uname -a
> Linux beefy 2.6.31-gentoo-r10 #6 SMP Tue Mar 30 18:36:29 MDT 2010
> x86_64 Intel(R) Xeon(TM) CPU 3.00GHz GenuineIntel GNU/Linux
>
> # fsck.reiser4 --version
> fsck.reiser4 1.0.7
> --
> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2010-04-11 23:57 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-11 3:47 fsck.reiser4 mishandling large files Morgan Smith
2010-04-11 23:57 ` Edward Shishkin
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 read-only IMAP folder(s) and NNTP newsgroup(s).