Re: corruption on my ext2fs with 2.4.0-test10
Mircea Damian writes:
> ... file-utils like ls, rm say:
> root@invasion:/usr/src/perl-5.6.0/t# ls -sail
> /bin/ls: big: Value too large for defined data type
> total 8
> 10973604 drwx-- 2 504 1001 4096 Dec 3 13:43 ./
> 13549794 drwxr-xr-x 3 504 1001 4096 Dec 3 13:43 ../
The file's got holes in it (regions of zeros), so it doesn't occupy as
much space on disk as it claims to. The reason your normal tools can't
deal with it is that your C library has been built without LFS
support, so stat will fail on files larger than 2 gig.
You can remove it by just calling unlink.
int main(int argc, char **argv) {
unlink("mybigfile");
}
--
Adam Sampson
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: corruption on my ext2fs with 2.4.0-test10
OK, problem found.
Something is broken (I've tested on a new 2.4.0-test12-pre3). Look here:
If I run strace through the perl script I get something like:
root@invasion:/usr/src/archives/perl-5.6.0/t# strace ./perl op/lfs.t
...
open("big", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40015000
_llseek(3, 50, [50], SEEK_SET) = 0
write(3, "big", 3) = 3
close(3)= 0
munmap(0x40015000, 4096)= 0
stat("big", 0xb980) = -1 EOVERFLOW (Value too large for defined
data type)
...
I believe that _llseek() call should return EINVAL. Right?
On Sun, Dec 03, 2000 at 02:46:06PM +0200, Mircea Damian wrote:
>
> Sorry that I have to follow my self but I forgot to say that e2fsck is
> happy with it:
>
> root@invasion:~# e2fsck -C 0 -f /dev/hda2
> e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> /dev/hda2: 43056/1548288 files (1.7% non-contiguous), 237689/1548264 blocks
>
> ... file-utils like ls, rm say:
> root@invasion:/usr/src/perl-5.6.0/t# ls -sail
> /bin/ls: big: Value too large for defined data type
> total 8
> 10973604 drwx-- 2 504 1001 4096 Dec 3 13:43 ./
> 13549794 drwxr-xr-x 3 504 1001 4096 Dec 3 13:43 ../
>
> root@invasion:/usr/src/perl-5.6.0/t# rm big
> rm: cannot remove `big': Value too large for defined data type
>
> I can not keep this machine down (my /-fs is read-only right now just to be
> sure that nothing changes) for too much time.
--
Mircea Damian
E-mails: [EMAIL PROTECTED], [EMAIL PROTECTED]
WebPage: http://taz.mania.k.ro/~dmircea/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: corruption on my ext2fs with 2.4.0-test10
Sorry that I have to follow my self but I forgot to say that e2fsck is happy with it: root@invasion:~# e2fsck -C 0 -f /dev/hda2 e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/hda2: 43056/1548288 files (1.7% non-contiguous), 237689/1548264 blocks ... file-utils like ls, rm say: root@invasion:/usr/src/perl-5.6.0/t# ls -sail /bin/ls: big: Value too large for defined data type total 8 10973604 drwx-- 2 504 1001 4096 Dec 3 13:43 ./ 13549794 drwxr-xr-x 3 504 1001 4096 Dec 3 13:43 ../ root@invasion:/usr/src/perl-5.6.0/t# rm big rm: cannot remove `big': Value too large for defined data type I can not keep this machine down (my /-fs is read-only right now just to be sure that nothing changes) for too much time. On Sun, Dec 03, 2000 at 02:24:33PM +0200, Mircea Damian wrote: > > Hello people, > > Since I've seen that there are some problems with corruption on ext2fs I > thought that it would be a good idea to report my problem too. > > I have a 2.4.0-test10 patched with reiserfs (but I do not use it - it was > just in my plan to create a partition sometime; so I think that it does not > matter to much). Kernel compiled with egcs-1.1.2: > > root@invasion:~# gcc -v > Reading specs from /usr/lib/gcc-lib/i386-slackware-linux/egcs-2.91.66/specs > gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) > > The problem is that I tried to build perl-5.6.0 and some of my tests were > failing. First I thought that it is a problem with shared libraries but I > was wrong, in the test directory I have a file named "big" which has 5Gb > (almost): > > root@invasion:/# debugfs /dev/hda2 > debugfs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 > debugfs: cd /usr/src/perl-5.6.0/t/ > debugfs: ls > 1097360 (12) . 1354979 (184) .. 1097503 (3900) big > debugfs: ls -l > 1097360 40700504 10014096 3-Dec-2000 13:43 . > 1354979 40755504 10014096 3-Dec-2000 13:43 .. > 1097503 100644 0 0 53 3-Dec-2000 10:00 big > > Ofcourse this is wrong because: > debugfs: q > root@invasion:/# df > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/hda2 5999072756772 4932648 13% / > > > I've checked my syslog and messages for ext2 warnings but I found nothing > unusual. > > The system is UP and dmesg output is attached. > > OTOH does anyone know how to silent messages like: > NAT: 0 dropping untracked packet c7d205c0 1 192.129.3.151 -> 224.0.0.1 > NAT: 0 dropping untracked packet c7d129a0 1 192.129.3.151 -> 224.0.0.1 > They are annoying and after some time they just fill up my dmesg output > (all dropped packets are multicast just like the two above). > > > > uto BOOT_IMAGE=Linux ro root=302 console=ttyS0,38400 > Initializing CPU#0 > Detected 400.914 MHz processor. > Console: colour VGA+ 80x30 > Calibrating delay loop... 799.54 BogoMIPS > Memory: 126788k/131072k available (1207k kernel code, 3896k reserved, 85k data, 196k >init, 0k highmem) > Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) > Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) > Page-cache hash table entries: 32768 (order: 5, 131072 bytes) > Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) > CPU: Before vendor init, caps: 0183fbff , vendor = 0 > CPU: L1 I cache: 16K, L1 D cache: 16K > CPU: L2 cache: 512K > Intel machine check architecture supported. > Intel machine check reporting enabled on CPU#0. > CPU: After vendor init, caps: 0183fbff > CPU: After generic, caps: 0183fbff > CPU: Common caps: 0183fbff > CPU: Intel Pentium II (Deschutes) stepping 02 > Checking 'hlt' instruction... OK. > POSIX conformance testing by UNIFIX > enabled ExtINT on CPU#0 > ESR value before enabling vector: 0004 > ESR value after enabling vector: > ENABLING IO-APIC IRQs > ...changing IO-APIC physical APIC ID to 2 ... ok. > Synchronizing Arb IDs. > init IO_APIC IRQs > IO-APIC (apicid-pin) 2-0, 2-16, 2-20, 2-21, 2-22, 2-23 not connected. > ..TIMER: vector=49 pin1=2 pin2=0 > activating NMI Watchdog ... done. > number of MP IRQ sources: 20. > number of IO-APIC #2 registers: 24. > testing the IO APIC... > > IO APIC #2.. > register #00: 0200 > ...: physical APIC id: 02 > register #01: 00170011 > ... : max redirection entries: 0017 > ... : IO APIC version: 0011 > register #02: > ... : arbitration: 00 > IRQ redirection table: > NR Log Phy Mask Trig IRR Po
corruption on my ext2fs with 2.4.0-test10
Hello people, Since I've seen that there are some problems with corruption on ext2fs I thought that it would be a good idea to report my problem too. I have a 2.4.0-test10 patched with reiserfs (but I do not use it - it was just in my plan to create a partition sometime; so I think that it does not matter to much). Kernel compiled with egcs-1.1.2: root@invasion:~# gcc -v Reading specs from /usr/lib/gcc-lib/i386-slackware-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) The problem is that I tried to build perl-5.6.0 and some of my tests were failing. First I thought that it is a problem with shared libraries but I was wrong, in the test directory I have a file named "big" which has 5Gb (almost): root@invasion:/# debugfs /dev/hda2 debugfs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 debugfs: cd /usr/src/perl-5.6.0/t/ debugfs: ls 1097360 (12) . 1354979 (184) .. 1097503 (3900) big debugfs: ls -l 1097360 40700504 10014096 3-Dec-2000 13:43 . 1354979 40755504 10014096 3-Dec-2000 13:43 .. 1097503 100644 0 0 53 3-Dec-2000 10:00 big Ofcourse this is wrong because: debugfs: q root@invasion:/# df Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda2 5999072756772 4932648 13% / I've checked my syslog and messages for ext2 warnings but I found nothing unusual. The system is UP and dmesg output is attached. OTOH does anyone know how to silent messages like: NAT: 0 dropping untracked packet c7d205c0 1 192.129.3.151 -> 224.0.0.1 NAT: 0 dropping untracked packet c7d129a0 1 192.129.3.151 -> 224.0.0.1 They are annoying and after some time they just fill up my dmesg output (all dropped packets are multicast just like the two above). -- Mircea Damian E-mails: [EMAIL PROTECTED], [EMAIL PROTECTED] WebPage: http://taz.mania.k.ro/~dmircea/ uto BOOT_IMAGE=Linux ro root=302 console=ttyS0,38400 Initializing CPU#0 Detected 400.914 MHz processor. Console: colour VGA+ 80x30 Calibrating delay loop... 799.54 BogoMIPS Memory: 126788k/131072k available (1207k kernel code, 3896k reserved, 85k data, 196k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) CPU: Before vendor init, caps: 0183fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0183fbff CPU: After generic, caps: 0183fbff CPU: Common caps: 0183fbff CPU: Intel Pentium II (Deschutes) stepping 02 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX enabled ExtINT on CPU#0 ESR value before enabling vector: 0004 ESR value after enabling vector: ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 2 ... ok. Synchronizing Arb IDs. init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-16, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=49 pin1=2 pin2=0 activating NMI Watchdog ... done. number of MP IRQ sources: 20. number of IO-APIC #2 registers: 24. testing the IO APIC... IO APIC #2.. register #00: 0200 ...: physical APIC id: 02 register #01: 00170011 ... : max redirection entries: 0017 ... : IO APIC version: 0011 register #02: ... : arbitration: 00 IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 100 0 00000 01 001 01 000 0 01139 02 001 01 000 0 01131 03 001 01 000 0 01141 04 001 01 000 0 01149 05 001 01 000 0 01151 06 001 01 000 0 01159 07 001 01 000 0 01161 08 001 01 000 0 01169 09 001 01 000 0 01171 0a 001 01 000 0 01179 0b 001 01 000 0 01181 0c 001 01 000 0 01189 0d 000 00 100 0 00000 0e 001 01 000 0 01191 0f 001 01 000 0 01199 10 000 00 100 0 00000 11 001 01 110 1 011A1 12 001 01 110 1 011A9 13 001 01 110 1 011B1 14 000 00 100 0 00000 15 000 00 100 0 00000 16 000 00 100 0 00000 17 000 00 100 0 00000 IRQ to pin mappings: IRQ0 -> 2 IRQ1 -> 1 IRQ3 -> 3 IRQ4 -> 4 IRQ5 -> 5 IRQ6 -> 6 IRQ7 -> 7 IRQ8 -> 8 IRQ9 -
