Hi,
On Mon, Mar 06, 2000 at 02:12:44PM -0500, Thomas Bushnell, BSG wrote:
> 1) The corruption always takes the form of a 4k aligned page of zeros
> showing up.
Unfortunately, no. The 4096 size is common in normal operation, but untar of
gcc gives 3*1024 size block, and I also saw one 2048 size block.
> 2) The corruption does not happen to directories.
Yes.
> 3) The corruption happens to both existing and new files.
Not sure. It definitely happens to new files, but I can't say that it
happens to existing files for sure. I will try to make some tests.
> 4) The corruption happens only when files are being extended.
I have not finished analyzing the debug log I produced, but in a couple of
cases it happened directly or shortly after a preallocation miss.
> 5) The corruption happens only in the middle of files.
No. It can be directly at the beginning, or the remaining bytes of a file.
(See the output of holefinder below, a number represents a 1024 byte chunk,
a number followed by a number in parentheses is the last chunk which is
shorter than 1024 (number in parentheses).
> 6) If you have a corrupt filesystem, and shut it down sanely, and then
> fsck it, fsck reports no errors. (In other words, the corruption
> is not associated with block map errors or such.)
Yes.
Here the number of "holes" after unpacking and configuring gcc:
Look at README, which is only 639 bytes long and completely consists of
NULLs. Lock at install-sh, which has NULLS at the beginning.
Look at recog.h, which has NULLs at the end.
All files except the small ones hae 4096 bytes long zero blocks, but I saw
3*1024 regularly, when just unpacking the Debian gcc_2.95.2.orig.tar.gz
file.
Another important info: The data remains intact in the "cache" (which one?),
read: As long as it is not reread from disk, it is okay. The corruption pops
up at a later time or after forcing an update with fsysopts -r; fsysopts -wu.
This is all I can say for sure. There are some other results, but they
are not safe but just impressions (for example, defining
DONT_CACHE_MEMORY_OBJECTS seems to decrease the likelihood of corruption
etc).
What Roland said is also true: When I set sync to a high value, and flush
collectively with fsysopts -r, the files were intact every time I tried (not
too often though).
Would be great to hear what you think about it. Spent the whole weekend on
this and found out almost nothing (also because I don't understand the hairy
paging code).
Thanks,
Marcus
./src/etc/standards.texi: 68, 69, 70, 71
./src/ChangeLog: 64, 65, 66, 67
./src/README: 0 (639)
./src/install-sh: 0, 1, 2, 3
./src/ltmain.sh: 52, 53, 54, 55
./src/gcc/ch/decl.c: 4, 5, 6, 7, 136, 137, 138, 139
./src/gcc/ch/inout.c: 0, 1, 2, 3
./src/gcc/ChangeLog.0: 84, 85, 86, 87, 240, 241, 242, 243, 372, 373, 374, 375
./src/gcc/ChangeLog.lib: 28, 29, 30, 31
./src/gcc/FSFChangeLog: 4, 5, 6, 7
./src/gcc/FSFChangeLog.11: 328, 329, 330, 331
./src/gcc/PROBLEMS: 4 (781)
./src/gcc/SERVICE: 28, 29, 30, 31
./src/gcc/c-lex.c: 56 (499)
./src/gcc/c-typeck.c: 52, 53, 54, 55, 120, 121, 122, 123
./src/gcc/calls.c: 32, 33, 34, 35, 120, 121, 122, 123
./src/gcc/combine.c: 152, 153, 154, 155, 248, 249, 250, 251, 352, 353, 354, 355
./src/gcc/cp/typeck2.c: 0, 1, 2, 3
./src/gcc/dwarf2out.c: 108, 109, 110, 111, 216, 217, 218, 219, 300, 301, 302, 303
./src/gcc/dwarfout.c: 116, 117, 118, 119
./src/gcc/except.h: 8, 9, 10, 11
./src/gcc/expmed.c: 32, 33, 34, 35
./src/gcc/final.c: 0, 1, 2, 3
./src/gcc/genattrtab.c: 56, 57, 58, 59
./src/gcc/genconfig.c: 0, 1, 2, 3
./src/gcc/haifa-sched.c: 152, 153, 154, 155
./src/gcc/install.texi: 96, 97, 98 (71)
./src/gcc/integrate.c: 104, 105, 106, 107
./src/gcc/intl.h: 0, 1 (371)
./src/gcc/local-alloc.c: 12, 13, 14, 15
./src/gcc/f/ChangeLog.0: 4, 5, 6, 7
./src/gcc/f/com.c: 112, 113, 114, 115, 228, 229, 230, 231
./src/gcc/f/expr.c: 4, 5, 6, 7, 108, 109, 110, 111
./src/gcc/f/ffe.texi: 32, 33, 34, 35
./src/gcc/f/g77.texi: 84, 85, 86, 87, 172, 173, 174, 175, 424, 425, 426, 427, 480,
481, 482, 483
./src/gcc/f/g77install.texi: 64, 65, 66, 67
./src/gcc/f/global.h: 4, 5, 6 (666)
./src/gcc/f/stb.c: 48, 49, 50, 51
./src/gcc/mips-tfile.c: 96, 97, 98, 99
./src/gcc/output.h: 4, 5, 6, 7
./src/gcc/real.c: 132, 133, 134, 135
./src/gcc/recog.h: 4, 5, 6, 7 (613)
./src/gcc/config/arc/arc.h: 24, 25, 26, 27
./src/gcc/config/arc/arc.md: 16, 17, 18, 19
./src/gcc/config/alpha/alpha-interix.h: 4, 5, 6, 7
./src/gcc/config/alpha/alpha.c: 84, 85, 86, 87
./src/gcc/config/alpha/alpha.md: 144, 145, 146, 147
./src/gcc/config/i386/crtdll.h: 0, 1 (645)
./src/gcc/config/i386/i386.h: 76, 77, 78, 79
./src/gcc/config/m68k/t-mot3300-gas: 0 (382)
./src/gcc/config/m68k/tower-as.h: 12, 13, 14, 15
./src/gcc/config/m68k/x-hp2bsd: 0 (139)
./src/gcc/p/.Make-lang.in.swp: 1, 2, 3, 5, 6, 7
./src/libio/ChangeLog: 24, 25, 26, 27
./src/libio/testsuite/lib/libio.exp: 4 (731)
./src/libobjc/THREADS: 8, 9, 10, 11
./src/libobjc/configure: 40, 41, 42, 43
./src/libobjc/thr-decosf1.c: 0, 1, 2, 3
./src/texinfo/libtxi/alloca.c: 0, 1, 2, 3
./src/FAQ: 24, 25, 26, 27
./src/.brik: 40, 41, 42, 43
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
[EMAIL PROTECTED], [EMAIL PROTECTED] PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
