Re: unmount issues with 2.4.5-ac5, 3ware, and ReiserFS (was: kernel-2.4.5
Looks like -ac6 has fixed this problem :) -- Leszek. -- [EMAIL PROTECTED] 2:480/33.7 -- REAL programmers use INTEGERS -- -- speaking just for myself... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unmount issues with 2.4.5-ac5, 3ware, and ReiserFS (was: kernel-2.4.5
> /dev/hda10/space1 reiserfsdefaults 1 2
/dev/sdb1 /var/log/LOGS reiserfs defaults 0 0
> strace umount /space1:
>
> open("/usr/lib/locale/en_US/LC_TIME", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=2441, ...}) = 0
> old_mmap(NULL, 2441, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001f000
> close(3)= 0
> open("/usr/lib/locale/en_US/LC_NUMERIC", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=44, ...}) = 0
> old_mmap(NULL, 44, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4002
> close(3)= 0
> open("/usr/lib/locale/en_US/LC_CTYPE", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=104804, ...}) = 0
> old_mmap(NULL, 104804, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40137000
> close(3)= 0
> SYS_199(0x40131ad8, 0, 0x40132760, 0x40130210, 0) = 0
> semop(1074993880, 0x40130210, 0)= 0
> brk(0x8056000) = 0x8056000
> readlink("/space1", 0xbfffe51c, 4095) = -1 EINVAL (Invalid argument)
> open("/etc/mtab", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=680, ...}) = 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>0x40021000
> read(3, "/dev/hde1 / ext2 rw 0 0\nproc /pr"..., 4096) = 680
> read(3, "", 4096) = 0
> close(3)= 0
> munmap(0x40021000, 4096)= 0
> oldumount("/space1"
strace /sbin/umount /dev/sdb1
execve("/sbin/umount", ["/sbin/umount", "/dev/sdb1"], [/* 30 vars */]) = 0
brk(0) = 0x80500c0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40016000
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(0x3, 0xbfffedb4)= 0
old_mmap(NULL, 37548, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000
close(3)= 0
open("/lib/libc.so.6", 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\264\323"..., 1024) = 1024
fstat64(0x3, 0xbfffedfc)= 0
old_mmap(NULL, 1116516, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40021000
mprotect(0x40128000, 39268, PROT_NONE) = 0
old_mmap(0x40128000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x106000)
= 0x40128000
old_mmap(0x4012e000, 14692, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x4012e000
close(3)= 0
munmap(0x40017000, 37548) = 0
getpid()= 421
brk(0) = 0x80500c0
brk(0x80500e8) = 0x80500e8
brk(0x8051000) = 0x8051000
SYS_199(0x4012ca58, 0, 0x4012d760, 0x4012b1f0, 0) = 0
semop(1074973272, 0x4012b1f0, 0)= 0
brk(0x8053000) = 0x8053000
readlink("/dev", 0xbfffe96c, 4095) = -1 EINVAL (Invalid argument)
readlink("/dev/sdb1", 0xbfffe96c, 4095) = -1 EINVAL (Invalid argument)
open("/etc/mtab", O_RDONLY|0x8000) = 3
fstat64(0x3, 0xb6ec)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40017000
read(3, "/dev/sda6 / ext2 rw 0 0\n/dev/sda"..., 4096) = 273
read(3, "", 4096) = 0
close(3)= 0
munmap(0x40017000, 4096)= 0
oldumount("/var/log/LOGS"
> and there it hangs. The kernel doesn't hang,
Ditto.
> but while 'mount' displays
> /space1 as mounted, ls /space1/ says nothing. df -m reveals:
>
> Filesystem 1M-blocks Used Available Use% Mounted on
> /dev/hda102015 907 1005 48% /space1
In my case:
- before umount:
root@logs2:/mnt# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda6 8130996 1356716 6354584 18% /
/dev/sda7 813099620 7711280 1% /spare
/dev/sda8 203847244 1933204 1% /home
/dev/sda9 2038472 41964 1891284 3% /tmp
/dev/sda1014016248 46444 13969804 1% /mnt
/dev/sdb1 35542688 32840 35509848 1% /mnt/log/LOGS
- after (unfinished od course) umount:
lech7@logs2:~$ df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda6 8130996 1356572 6354728 18% /
/dev/sda7 813099620 7711280 1% /spare
/dev/sda8 203847244 1933204 1% /home
/dev/sda9 2038472 41968 1891280 3% /tmp
/dev/sda1014016248 46540 13969708 1% /var
/dev/sdb1 14016248 46540 13969708 1% /var/log/LOGS
--
Leszek.
-- [EMAIL PROTECTED] 2:480/33.7 -- REAL programmers use INTEGERS --
-- speaking just for myself...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Re: unmount issues with 2.4.5-ac5, 3ware, and ReiserFS (was: kernel-2.4.5
/dev/hda10/space1 reiserfsdefaults 1 2
/dev/sdb1 /var/log/LOGS reiserfs defaults 0 0
strace umount /space1:
open(/usr/lib/locale/en_US/LC_TIME, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2441, ...}) = 0
old_mmap(NULL, 2441, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001f000
close(3)= 0
open(/usr/lib/locale/en_US/LC_NUMERIC, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=44, ...}) = 0
old_mmap(NULL, 44, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4002
close(3)= 0
open(/usr/lib/locale/en_US/LC_CTYPE, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=104804, ...}) = 0
old_mmap(NULL, 104804, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40137000
close(3)= 0
SYS_199(0x40131ad8, 0, 0x40132760, 0x40130210, 0) = 0
semop(1074993880, 0x40130210, 0)= 0
brk(0x8056000) = 0x8056000
readlink(/space1, 0xbfffe51c, 4095) = -1 EINVAL (Invalid argument)
open(/etc/mtab, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=680, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40021000
read(3, /dev/hde1 / ext2 rw 0 0\nproc /pr..., 4096) = 680
read(3, , 4096) = 0
close(3)= 0
munmap(0x40021000, 4096)= 0
oldumount(/space1
strace /sbin/umount /dev/sdb1
execve(/sbin/umount, [/sbin/umount, /dev/sdb1], [/* 30 vars */]) = 0
brk(0) = 0x80500c0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40016000
open(/etc/ld.so.preload, O_RDONLY)= -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(0x3, 0xbfffedb4)= 0
old_mmap(NULL, 37548, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000
close(3)= 0
open(/lib/libc.so.6, 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\264\323..., 1024) = 1024
fstat64(0x3, 0xbfffedfc)= 0
old_mmap(NULL, 1116516, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40021000
mprotect(0x40128000, 39268, PROT_NONE) = 0
old_mmap(0x40128000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x106000)
= 0x40128000
old_mmap(0x4012e000, 14692, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x4012e000
close(3)= 0
munmap(0x40017000, 37548) = 0
getpid()= 421
brk(0) = 0x80500c0
brk(0x80500e8) = 0x80500e8
brk(0x8051000) = 0x8051000
SYS_199(0x4012ca58, 0, 0x4012d760, 0x4012b1f0, 0) = 0
semop(1074973272, 0x4012b1f0, 0)= 0
brk(0x8053000) = 0x8053000
readlink(/dev, 0xbfffe96c, 4095) = -1 EINVAL (Invalid argument)
readlink(/dev/sdb1, 0xbfffe96c, 4095) = -1 EINVAL (Invalid argument)
open(/etc/mtab, O_RDONLY|0x8000) = 3
fstat64(0x3, 0xb6ec)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40017000
read(3, /dev/sda6 / ext2 rw 0 0\n/dev/sda..., 4096) = 273
read(3, , 4096) = 0
close(3)= 0
munmap(0x40017000, 4096)= 0
oldumount(/var/log/LOGS
and there it hangs. The kernel doesn't hang,
Ditto.
but while 'mount' displays
/space1 as mounted, ls /space1/ says nothing. df -m reveals:
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/hda102015 907 1005 48% /space1
In my case:
- before umount:
root@logs2:/mnt# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda6 8130996 1356716 6354584 18% /
/dev/sda7 813099620 7711280 1% /spare
/dev/sda8 203847244 1933204 1% /home
/dev/sda9 2038472 41964 1891284 3% /tmp
/dev/sda1014016248 46444 13969804 1% /mnt
/dev/sdb1 35542688 32840 35509848 1% /mnt/log/LOGS
- after (unfinished od course) umount:
lech7@logs2:~$ df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda6 8130996 1356572 6354728 18% /
/dev/sda7 813099620 7711280 1% /spare
/dev/sda8 203847244 1933204 1% /home
/dev/sda9 2038472 41968 1891280 3% /tmp
/dev/sda1014016248 46540 13969708 1% /var
/dev/sdb1 14016248 46540 13969708 1% /var/log/LOGS
--
Leszek.
-- [EMAIL PROTECTED] 2:480/33.7 -- REAL programmers use INTEGERS --
-- speaking just for myself...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: unmount issues with 2.4.5-ac5, 3ware, and ReiserFS (was: kernel-2.4.5
Looks like -ac6 has fixed this problem :) -- Leszek. -- [EMAIL PROTECTED] 2:480/33.7 -- REAL programmers use INTEGERS -- -- speaking just for myself... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: quotaon -guav on 2.4.1-ac15
> quotaon: using /home/vhosts/b/quota.user on /dev/sda3: Invalid argument > quotaon: using /home/vhosts/a/quota.user on /dev/sdb1: Invalid argument I believe -ac family has Jan Kara quota patches and therefore you need his quota-3 utilites, avaliable from ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/utils -- Leszek. -- [EMAIL PROTECTED] 2:480/33.7 -- REAL programmers use INTEGERS -- -- speaking just for myself... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: quotaon -guav on 2.4.1-ac15
quotaon: using /home/vhosts/b/quota.user on /dev/sda3: Invalid argument quotaon: using /home/vhosts/a/quota.user on /dev/sdb1: Invalid argument I believe -ac family has Jan Kara quota patches and therefore you need his quota-3 utilites, avaliable from ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/utils -- Leszek. -- [EMAIL PROTECTED] 2:480/33.7 -- REAL programmers use INTEGERS -- -- speaking just for myself... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Can't boot AsusA7V+Tbird with Linux2.2.X?
> I got my new AsusA7V motherboard and AMD Thunderbird > booting RedHat5.2/linux2.0.36 with no trouble. (A dusty > old RH5.2 CD was all I had handy at the time) I then > downloaded the 2.2.17 and 2.4.0test8 sources and built > them, only to find that neither would even TRY to boot; I have A7V rel 1.02 with Thunderbird 750 and it runs 2.2.17 and 2.4.0-test[67] just fine. -- Leszek. -- [EMAIL PROTECTED] 2:480/33.7 -- REAL programmers use INTEGERS -- -- speaking just for myself... - 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: MTBF data for linux
> > We ran 1.2.13lmp for about 1100 days before the box finally got > > turned off - twice around the uptime clock and more > That's must be some kind of unofficial record... I though 400+ days > was pretty neat, but 1100 says is really impressive, especially on a > kernel which has races with jiffie wraps... As Alan wrote, dedicated-to-one-job servers can be quite stable; here's something from one of our mailservers: 10:46 [poczta(p0)$/home/lech7] last -6 reboot reboot~ Thu Jun 16 07:35 [2000] reboot~ Thu Jun 16 07:35 [2000] reboot~ Wed Jun 1 14:11 [2000] reboot~ Wed Jun 1 14:11 [2000] reboot~ Tue Sep 24 20:27 [1996] reboot~ Tue Sep 24 20:27 [1996] reboot~ Mon Sep 16 16:03 [1996] reboot~ Mon Sep 16 16:03 [1996] I added year in square brackets, to make the right impression: 1375 days... :) -- Leszek. -- [EMAIL PROTECTED] 2:480/33.7 -- REAL programmers use INTEGERS -- -- speaking just for myself... - 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: MTBF data for linux
We ran 1.2.13lmp for about 1100 days before the box finally got turned off - twice around the uptime clock and more That's must be some kind of unofficial record... I though 400+ days was pretty neat, but 1100 says is really impressive, especially on a kernel which has races with jiffie wraps... As Alan wrote, dedicated-to-one-job servers can be quite stable; here's something from one of our mailservers: 10:46 [poczta(p0)$/home/lech7] last -6 reboot reboot~ Thu Jun 16 07:35 [2000] reboot~ Thu Jun 16 07:35 [2000] reboot~ Wed Jun 1 14:11 [2000] reboot~ Wed Jun 1 14:11 [2000] reboot~ Tue Sep 24 20:27 [1996] reboot~ Tue Sep 24 20:27 [1996] reboot~ Mon Sep 16 16:03 [1996] reboot~ Mon Sep 16 16:03 [1996] I added year in square brackets, to make the right impression: 1375 days... :) -- Leszek. -- [EMAIL PROTECTED] 2:480/33.7 -- REAL programmers use INTEGERS -- -- speaking just for myself... - 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/
