From owner-linux-xfs@oss.sgi.com Sat Sep 1 04:42:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81Bg1j10325 for linux-xfs-outgoing; Sat, 1 Sep 2001 04:42:01 -0700 Received: from st-peter.stw.uni-erlangen.de (IDENT:qmailr@voyager.st-peter.stw.uni-erlangen.de [131.188.24.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81Bfld10300 for ; Sat, 1 Sep 2001 04:41:47 -0700 Received: (qmail 4750 invoked from network); 1 Sep 2001 11:41:46 -0000 Received: from svetljo.st-peter.stw.uni-erlangen.de (HELO st-peter.stw.uni-erlangen.de) (172.17.17.181) by voyager.st-peter.stw.uni-erlangen.de with SMTP; 1 Sep 2001 11:41:46 -0000 Message-ID: <3B90C9A4.3080005@st-peter.stw.uni-erlangen.de> Date: Sat, 01 Sep 2001 13:42:28 +0200 From: svetljo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com, raiddev@nuclecu.unam.mx, linux-lvm@sistina.com Subject: Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?) References: <3B8E3F0E.8050609@st-peter.stw.uni-erlangen.de> <20010830083546.A20989@sistina.com> <3B8EC633.40202@st-peter.stw.uni-erlangen.de> <3B8F8C5E.7030603@st-peter.stw.uni-erlangen.de> <20010831110512.V541@turbolinux.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi a small adition i've tried to format the LV with ext2 and reiserfs, but it didn't worked : mkfs segfaults a strange one : i'm able to format with IBM JFS , and i can work without a problem with the LV everything just to be fine with JFS i'm currently building: clean 2.4.9-linus with LVM-1.0.1rc1 2.4.9-ac5 with LVM-1.0 ( i couldn't do it with LVM-1.0.1rc1 & rc2) 2.4.10-pre2-xfs-cvs with LVM-1.0.1rc2 to find out what is going on with ext2 reiserfs XFS , is the problem coming from the XFS kernel changes >Hi >i'm having a serios trouble with creating >a LVM over software linear RAID >well i created it, formated it with XFS >but every time i try to mount the LV mount segfaults >and then i can not mount any other file system ( partition, CD, .. >until i reboot, when i try to mount smth mount simple stop to respond >without an error and blocks the console > >i'm using XFS cvs kernel 2.4.9 and LVM-1.0.1rc1 >on ABIT's BP6 2xCelleron 533 512Mb RAM >the drives are on onboard HPT366 controler 2xWD 30Gb 1xMaxtor 40Gb > >the LV is striped over the 3 devices of the VG >the VG is /dev/hdh10 /dev/md6 /dev/md7 >/dev/md6 is linear software RAID /dev/hde6 /dev/hde12 >/dev/md7 is linear software RAID /dev/hdg1 /dev/hdg5 /dev/hdg6 >dev/hdg11 > >i posted to the LVM-lists and there i was told >to try "dmesg | ksymoops" > >and i became the folowing answer > > > >>EIP; e29c0266 <[linear]linear_make_request+36/f0> <===== > > > >> Trace; c023fa12 <__make_request+412/6d0> > >> Trace; c0278dcd > >> Trace; c027fa0f > >> Trace; c023fd89 > > > >OK, so the oops is inside the RAID layer, but it may be that it is > >being fed bogus data from a higher layer. Even so, it should not > >oops in this case. Since XFS changes a lot of the kernel code, I > >would either suggest asking the XFS folks to look at this oops, > >or maybe on the MD RAID mailing list, as they will know more about >it. > >this is the full "dmesg | ksymoops" , i'll try to use other FS to find >out whether it's a problem with XFS, but i wish me not to have to use >other FS, i realy love XFS Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010247 eax: 004ac1ab ebx: 004ac1ab ecx: 00000000 edx: 00000000 esi: d54eb320 edi: c188b928 ebp: 00958357 esp: d4eb3670 ds: 0018 es: 0018 ss: 0018 Process mount (pid: 5536, stackpage=d4eb3000) Stack: d54eb3e0 c023fa12 00000907 d54eb320 00000000 01c02000 c0278dcd dcec43c0 00000000 d54eb320 d54eb320 00000000 01c02000 c027fa0f 00000001 d54eb320 c023fd89 c03a7254 00000000 d54eb320 00000282 00000021 00000000 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: f7 f9 85 d2 74 24 55 51 68 c0 03 9c e2 e8 58 6c 75 dd 6a 00 >>EIP; e29c0266 <[linear]linear_make_request+36/f0> <===== Trace; c023fa12 <__make_request+412/6d0> Trace; c0278dcd Trace; c027fa0f Trace; c023fd89 Trace; c01a6814 <_pagebuf_page_io+1f4/370> Trace; c01a6a85 <_page_buf_page_apply+f5/1c0> Trace; c01a6fc1 Trace; c01a6c47 Trace; c01a6990 <_page_buf_page_apply+0/1c0> Trace; c0105dac <__down+bc/d0> Trace; c0105f1c <__down_failed+8/c> Trace; c02e2140 Trace; c021c10a Trace; c01fe5b8 Trace; c01ff2a4 Trace; c01a553e <_pagebuf_get_object+3e/170> Trace; c01feb6f Trace; c01feed8 Trace; c01fc322 Trace; c0201f40 Trace; c01fb8f3 Trace; c0202fdf Trace; c02026bf Trace; c01a60be Trace; c02026eb Trace; c021e674 Trace; c020b69c Trace; c020b843 Trace; c020b871 Trace; c021cf48 Trace; c01294e0 Trace; c0125f0e Trace; c0125d9d Trace; c013cd72 Trace; c013d01b Trace; c013dafc Trace; c01131e0 Trace; c010724c Trace; c013dd56 Trace; c013dbfc Trace; c013de13 Trace; c010715b Code; e29c0266 <[linear]linear_make_request+36/f0> 00000000 <_EIP>: Code; e29c0266 <[linear]linear_make_request+36/f0> <===== 0: f7 f9 idiv %ecx,%eax <===== Code; e29c0268 <[linear]linear_make_request+38/f0> 2: 85 d2 test %edx,%edx Code; e29c026a <[linear]linear_make_request+3a/f0> 4: 74 24 je 2a <_EIP+0x2a> e29c0290 <[linear]linear_make_request+60/f0> Code; e29c026c <[linear]linear_make_request+3c/f0> 6: 55 push %ebp Code; e29c026d <[linear]linear_make_request+3d/f0> 7: 51 push %ecx Code; e29c026e <[linear]linear_make_request+3e/f0> 8: 68 c0 03 9c e2 push $0xe29c03c0 Code; e29c0273 <[linear]linear_make_request+43/f0> d: e8 58 6c 75 dd call dd756c6a <_EIP+0xdd756c6a> c0116ed0 Code; e29c0278 <[linear]linear_make_request+48/f0> 12: 6a 00 push $0x0 Andreas Dilger wrote: >On Aug 31, 2001 15:08 +0200, svetljo wrote: > >>[root@svetljo mnt]# mount -t xfs /dev/myData/Music music >>Segmentation fault >> > >Generally this is a bad sign. Either mount is segfaulting (unlikely) >or you are getting an oops in the kernel. You need do run something >like "dmesg | ksymoops" in order to get some useful data about where >the problem is (could be xfs, LVM, or elsewhere in the kernel). > >Once you have an oops, you are best off rebooting the system, because >your kernel memory may be corrupted, and cause more oopses which do >not mean anything. If you look in /var/log/messages (or /var/log/kern.log >or some other place, depending on where kernel messages go), you can >decode the FIRST oops in the log with ksymoops. All subsequent ones are >useless. > > >>the LV ( lvcreate -i3 -I4 -L26G -nMusic ) >> >>the VG -> myData /dev/hdh10 /dev/linVG1/linLV1 /dev/linVG2/linLV2 >> >>/dev/hdh10 normal partition 14G >>/dev/linVG1/linLV1 -> linear LV 14G /dev/hde6 /dev/hde12 >>/dev/linVg2/linLV2 -> linear LV 14G /dev/hdg1 /dev/hdg5 /dev/hdg6 /dev/hdg12 >> > >There is absolutely no point in doing this (not that it is possible to do >so anyways). First of all, striping is almost never needed "for performance" >unless you are normally doing very large sequential I/Os, and even so most >disks today have very good sequential I/O rates (e.g. 15-30MB/s). Secondly, >you _should_ be able to just create a single LV that is striped across all >of the PVs above. You would likely need to build it in steps, to ensure >that it is striped across the disks correctly. > >Cheers, Andreas > From owner-linux-xfs@oss.sgi.com Sat Sep 1 07:20:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81EKQY12721 for linux-xfs-outgoing; Sat, 1 Sep 2001 07:20:26 -0700 Received: from st-peter.stw.uni-erlangen.de (IDENT:qmailr@voyager.st-peter.stw.uni-erlangen.de [131.188.24.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81EKDd12701 for ; Sat, 1 Sep 2001 07:20:13 -0700 Received: (qmail 8400 invoked from network); 1 Sep 2001 14:20:11 -0000 Received: from svetljo.st-peter.stw.uni-erlangen.de (HELO st-peter.stw.uni-erlangen.de) (172.17.17.181) by voyager.st-peter.stw.uni-erlangen.de with SMTP; 1 Sep 2001 14:20:11 -0000 Message-ID: <3B90EEC8.3030402@st-peter.stw.uni-erlangen.de> Date: Sat, 01 Sep 2001 16:20:56 +0200 From: svetljo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-lvm@sistina.com, linux-xfs@oss.sgi.com, akpm@zip.com.au, neilb@cse.unsw.edu.au Subject: Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?) References: <3B8E3F0E.8050609@st-peter.stw.uni-erlangen.de> <20010830083546.A20989@sistina.com> <3B8EC633.40202@st-peter.stw.uni-erlangen.de> <3B8F8C5E.7030603@st-peter.stw.uni-erlangen.de> <20010831110512.V541@turbolinux.com> <3B90C9A4.3080005@st-peter.stw.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk and here are the results of mkfs ############################################################### ######### linus-2.4.9 lvm-1.0.1rc1 ################### ############################################################### [root@svetljo root]# mkfs -t reiserfs -f /dev/myData/SRC mkreiserfs, 2001 - reiserfsprogs 3.x.0j =================================================================== LEAF NODE (8211) contains level=1, nr_items=2, free_space=3932 rdkey ------------------------------------------------------------------------------- |###|type|ilen|f/sp| loc|fmt|fsck| key | | | | |e/cn| | |need| | ------------------------------------------------------------------------------- Segmentation fault [root@svetljo root]# mkfs -t ext2 -f /dev/myData/SRC mke2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09 mkfs.ext2: bad fragment size - /dev/myData/SRC ################################################################ ########### linux-2.4.9-ac5 lvm-1.0 ######################## ################################################################ [root@svetljo root]# mkfs -t reiserfs /dev/myData/SRC mkreiserfs, 2001 - reiserfsprogs 3.x.0j =================================================================== LEAF NODE (8211) contains level=1, nr_items=2, free_space=3932 rdkey ------------------------------------------------------------------------------- |###|type|ilen|f/sp| loc|fmt|fsck| key | | | | |e/cn| | |need| | ------------------------------------------------------------------------------- Segmentation fault [root@svetljo root]# mkfs -t reiserfs -f /dev/myData/SRC mkreiserfs, 2001 - reiserfsprogs 3.x.0j =================================================================== LEAF NODE (8211) contains level=1, nr_items=2, free_space=3932 rdkey ------------------------------------------------------------------------------- |###|type|ilen|f/sp| loc|fmt|fsck| key | | | | |e/cn| | |need| | ------------------------------------------------------------------------------- Segmentation fault [root@svetljo root]# mkfs -t ext2 -f /dev/myData/SRC mke2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09 mkfs.ext2: bad fragment size - /dev/myData/SRC [root@svetljo root]# mkfs -t ext2 /dev/myData/SRC mke2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 786432 inodes, 1572864 blocks 78643 blocks (5.00%) reserved for the super user First data block=0 48 block groups 32768 blocks per group, 32768 fragments per group 16384 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736 Writing inode tables: Segmentation fault ##################################################################### ### and linux-2.4.10-pre2-xfs lvm-1.0.1rc2 ####### ##################################################################### [root@svetljo root]# mkfs -t reiserfs /dev/myData/SRC mkreiserfs, 2001 - reiserfsprogs 3.x.0j =================================================================== LEAF NODE (8211) contains level=1, nr_items=2, free_space=3932 rdkey ------------------------------------------------------------------------------- |###|type|ilen|f/sp| loc|fmt|fsck| key | | | | |e/cn| | |need| | ------------------------------------------------------------------------------- Segmentation fault [root@svetljo root]# mkfs -t reiserfs -f /dev/myData/SRC mkreiserfs, 2001 - reiserfsprogs 3.x.0j =================================================================== LEAF NODE (8211) contains level=1, nr_items=2, free_space=3932 rdkey ------------------------------------------------------------------------------- |###|type|ilen|f/sp| loc|fmt|fsck| key | | | | |e/cn| | |need| | ------------------------------------------------------------------------------- Segmentation fault [root@svetljo root]# mkfs -t ext2 /dev/myData/SRC mke2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 786432 inodes, 1572864 blocks 78643 blocks (5.00%) reserved for the super user First data block=0 48 block groups 32768 blocks per group, 32768 fragments per group 16384 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736 Writing inode tables: Segmentation fault [root@svetljo root]# mkfs -t ext2 -f /dev/myData/SRC mke2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09 mkfs.ext2: bad fragment size - /dev/myData/SRC [root@svetljo root]# mkfs -t xfs /dev/myData/SRC meta-data=/dev/myData/SRC isize=256 agcount=8, agsize=196608 blks data = bsize=4096 blocks=1572864, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 [root@svetljo root]# mkfs -t xfs -f /dev/myData/SRC meta-data=/dev/myData/SRC isize=256 agcount=8, agsize=196608 blks data = bsize=4096 blocks=1572864, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 From owner-linux-xfs@oss.sgi.com Sat Sep 1 07:30:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81EUBq13030 for linux-xfs-outgoing; Sat, 1 Sep 2001 07:30:11 -0700 Received: from st-peter.stw.uni-erlangen.de (IDENT:qmailr@voyager.st-peter.stw.uni-erlangen.de [131.188.24.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81ETqd12999 for ; Sat, 1 Sep 2001 07:29:52 -0700 Received: (qmail 5989 invoked from network); 1 Sep 2001 14:10:44 -0000 Received: from svetljo.st-peter.stw.uni-erlangen.de (HELO st-peter.stw.uni-erlangen.de) (172.17.17.181) by voyager.st-peter.stw.uni-erlangen.de with SMTP; 1 Sep 2001 14:10:44 -0000 Message-ID: <3B90EC90.4050606@st-peter.stw.uni-erlangen.de> Date: Sat, 01 Sep 2001 16:11:28 +0200 From: svetljo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-lvm@sistina.com, linux-xfs@oss.sgi.com, akpm@zip.com.au, neilb@cse.unsw.edu.au Subject: Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?) References: <3B8E3F0E.8050609@st-peter.stw.uni-erlangen.de> <20010830083546.A20989@sistina.com> <3B8EC633.40202@st-peter.stw.uni-erlangen.de> <3B8F8C5E.7030603@st-peter.stw.uni-erlangen.de> <20010831110512.V541@turbolinux.com> <3B90C9A4.3080005@st-peter.stw.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk well i did the tests clean Linus kernel-2.4.9 LVM-1.0.1rc1 ext2 and reiserfs segfaults clean linux-2.4.9-ac5 LVM-1.0 ext2 and reiserfs segfaults | linux-2.4.10-pre2-xfs LVM-1.0.1rc2 ext2 and reiserfs segfaults, but xfs seems to work | from SGI's cvs tree linux-2.4-xfs taken today in the early morning i'll try to ad IBM's JFS and try it again and i'll try bonnie on them can you give me ideas how to stres the FS to find out whether it realy works with XFS and JFS what could be wrong with ext2 and reiserfs as it works with JFS-1.0.3 and with the latest cvs XFS svetljo wrote: > Hi > > a small adition i've tried to format the LV with ext2 and reiserfs, > but it didn't worked : mkfs segfaults > a strange one : i'm able to format with IBM JFS , and i can work > without a problem with the LV everything just to be fine with JFS > > i'm currently building: > clean 2.4.9-linus with LVM-1.0.1rc1 > 2.4.9-ac5 with LVM-1.0 ( i couldn't do it with LVM-1.0.1rc1 & rc2) > 2.4.10-pre2-xfs-cvs with LVM-1.0.1rc2 > to find out what is going on with ext2 reiserfs XFS , > is the problem coming from the XFS kernel changes > > >Hi > >i'm having a serios trouble with creating > >a LVM over software linear RAID > >well i created it, formated it with XFS > >but every time i try to mount the LV mount segfaults > >and then i can not mount any other file system ( partition, CD, .. > >until i reboot, when i try to mount smth mount simple stop to respond > >without an error and blocks the console > > > >i'm using XFS cvs kernel 2.4.9 and LVM-1.0.1rc1 > >on ABIT's BP6 2xCelleron 533 512Mb RAM > >the drives are on onboard HPT366 controler 2xWD 30Gb 1xMaxtor 40Gb > > > >the LV is striped over the 3 devices of the VG > >the VG is /dev/hdh10 /dev/md6 /dev/md7 > >/dev/md6 is linear software RAID /dev/hde6 /dev/hde12 > >/dev/md7 is linear software RAID /dev/hdg1 /dev/hdg5 /dev/hdg6 > >dev/hdg11 > > > >i posted to the LVM-lists and there i was told > >to try "dmesg | ksymoops" > > > >and i became the folowing answer > > > > > >>EIP; e29c0266 <[linear]linear_make_request+36/f0> <===== > > > > > >> Trace; c023fa12 <__make_request+412/6d0> > > >> Trace; c0278dcd > > >> Trace; c027fa0f > > >> Trace; c023fd89 > > > > > >OK, so the oops is inside the RAID layer, but it may be that it is > > >being fed bogus data from a higher layer. Even so, it should not > > >oops in this case. Since XFS changes a lot of the kernel code, I > > >would either suggest asking the XFS folks to look at this oops, > > >or maybe on the MD RAID mailing list, as they will know more about > >it. > > > >this is the full "dmesg | ksymoops" , i'll try to use other FS to find > >out whether it's a problem with XFS, but i wish me not to have to use > >other FS, i realy love XFS > > > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010247 > eax: 004ac1ab ebx: 004ac1ab ecx: 00000000 edx: 00000000 > esi: d54eb320 edi: c188b928 ebp: 00958357 esp: d4eb3670 > ds: 0018 es: 0018 ss: 0018 > Process mount (pid: 5536, stackpage=d4eb3000) > Stack: d54eb3e0 c023fa12 00000907 d54eb320 00000000 01c02000 c0278dcd > dcec43c0 > 00000000 d54eb320 d54eb320 00000000 01c02000 c027fa0f 00000001 > d54eb320 > c023fd89 c03a7254 00000000 d54eb320 00000282 00000021 00000000 > 00000000 > Call Trace: [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] [] > [] > [] > Code: f7 f9 85 d2 74 24 55 51 68 c0 03 9c e2 e8 58 6c 75 dd 6a 00 > > >>EIP; e29c0266 <[linear]linear_make_request+36/f0> <===== > Trace; c023fa12 <__make_request+412/6d0> > Trace; c0278dcd > Trace; c027fa0f > Trace; c023fd89 > Trace; c01a6814 <_pagebuf_page_io+1f4/370> > Trace; c01a6a85 <_page_buf_page_apply+f5/1c0> > Trace; c01a6fc1 > Trace; c01a6c47 > Trace; c01a6990 <_page_buf_page_apply+0/1c0> > Trace; c0105dac <__down+bc/d0> > Trace; c0105f1c <__down_failed+8/c> > Trace; c02e2140 > Trace; c021c10a > Trace; c01fe5b8 > Trace; c01ff2a4 > Trace; c01a553e <_pagebuf_get_object+3e/170> > Trace; c01feb6f > Trace; c01feed8 > Trace; c01fc322 > Trace; c0201f40 > Trace; c01fb8f3 > Trace; c0202fdf > Trace; c02026bf > Trace; c01a60be > Trace; c02026eb > Trace; c021e674 > Trace; c020b69c > Trace; c020b843 > Trace; c020b871 > Trace; c021cf48 > Trace; c01294e0 > Trace; c0125f0e > Trace; c0125d9d > Trace; c013cd72 > Trace; c013d01b > Trace; c013dafc > Trace; c01131e0 > Trace; c010724c > Trace; c013dd56 > Trace; c013dbfc > Trace; c013de13 > Trace; c010715b > Code; e29c0266 <[linear]linear_make_request+36/f0> > 00000000 <_EIP>: > Code; e29c0266 <[linear]linear_make_request+36/f0> <===== > 0: f7 f9 idiv %ecx,%eax <===== > Code; e29c0268 <[linear]linear_make_request+38/f0> > 2: 85 d2 test %edx,%edx > Code; e29c026a <[linear]linear_make_request+3a/f0> > 4: 74 24 je 2a <_EIP+0x2a> e29c0290 > <[linear]linear_make_request+60/f0> > Code; e29c026c <[linear]linear_make_request+3c/f0> > 6: 55 push %ebp > Code; e29c026d <[linear]linear_make_request+3d/f0> > 7: 51 push %ecx > Code; e29c026e <[linear]linear_make_request+3e/f0> > 8: 68 c0 03 9c e2 push $0xe29c03c0 > Code; e29c0273 <[linear]linear_make_request+43/f0> > d: e8 58 6c 75 dd call dd756c6a <_EIP+0xdd756c6a> > c0116ed0 > Code; e29c0278 <[linear]linear_make_request+48/f0> > 12: 6a 00 push $0x0 > > Andreas Dilger wrote: > > >On Aug 31, 2001 15:08 +0200, svetljo wrote: > > > >>[root@svetljo mnt]# mount -t xfs /dev/myData/Music music > >>Segmentation fault > >> > > > >Generally this is a bad sign. Either mount is segfaulting (unlikely) > >or you are getting an oops in the kernel. You need do run something > >like "dmesg | ksymoops" in order to get some useful data about where > >the problem is (could be xfs, LVM, or elsewhere in the kernel). > > > >Once you have an oops, you are best off rebooting the system, because > >your kernel memory may be corrupted, and cause more oopses which do > >not mean anything. If you look in /var/log/messages (or > /var/log/kern.log > >or some other place, depending on where kernel messages go), you can > >decode the FIRST oops in the log with ksymoops. All subsequent ones > are > >useless. > > > > > >>the LV ( lvcreate -i3 -I4 -L26G -nMusic ) > >> > >>the VG -> myData /dev/hdh10 /dev/linVG1/linLV1 /dev/linVG2/linLV2 > >> > >>/dev/hdh10 normal partition 14G > >>/dev/linVG1/linLV1 -> linear LV 14G /dev/hde6 /dev/hde12 > >>/dev/linVg2/linLV2 -> linear LV 14G /dev/hdg1 /dev/hdg5 /dev/hdg6 > /dev/hdg12 > >> > > > >There is absolutely no point in doing this (not that it is possible > to do > >so anyways). First of all, striping is almost never needed "for > performance" > >unless you are normally doing very large sequential I/Os, and even > so most > >disks today have very good sequential I/O rates (e.g. 15-30MB/s). > Secondly, > >you _should_ be able to just create a single LV that is striped > across all > >of the PVs above. You would likely need to build it in steps, to > ensure > >that it is striped across the disks correctly. > > > >Cheers, Andreas > > > > > > > From owner-linux-xfs@oss.sgi.com Sat Sep 1 09:11:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81GBnn14749 for linux-xfs-outgoing; Sat, 1 Sep 2001 09:11:49 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81GBad14730 for ; Sat, 1 Sep 2001 09:11:36 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 4EBB467040; Sat, 1 Sep 2001 18:11:30 +0200 (CEST) To: Seth Mos Cc: linux-xfs@oss.sgi.com, Michael Wahlbrink Subject: Re: Kernel Oops ..... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Sat, 1 Sep 2001 18:11:28 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 01.09.2001 18:11:32, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 01.09.2001 18:11:32, Serialize complete at 01.09.2001 18:11:32, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 01.09.2001 18:11:33, S/MIME Sign complete at 01.09.2001 18:11:33, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 01.09.2001 18:11:33, Serialize complete at 01.09.2001 18:11:33, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 01.09.2001 18:11:30, Serialize complete at 01.09.2001 18:11:30 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z44518_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z44518_boundary_sign Content-Type: text/plain; charset="us-ascii" On 31.08.2001 23:57:07 Seth Mos wrote: >On Fri, 31 Aug 2001, Michael Wahlbrink wrote: > >> On 31.08.2001 23:12:22 Seth Mos wrote: >> >On Fri, 31 Aug 2001, Eric Sandeen wrote: >> > >> >> Michael Wahlbrink wrote: >> >> >> >> > Hi eric, >> >> > I've read this, but where I can get this egs for the suse 7.2 >which >> >I have >> >> > to use (company standard..... I would prefer debian.......)?? >> >> > >> >> > So I hope you can help me.... >> >> >> >> Hi Michael - >> >> >> >> I _think_ you could use Red Hat's compat-egcs and compat-glibc RPMs >> >on a >> >> SuSE system, to get this compiler - can any of the SuSE-users >verify >> >> that this is OK? >> > >> >I have seen reports that it can succesfully be used on SuSE. I >believe >> >this is what most people are doing right now. >> > >> >Cheers >> Ok I've downloaded and installed these rpms, now my stupid question: >what >> I've to do, that these other Compiler will be used (change the >'cc-link' >> to the kgcc??)???? I'm now so far with xfs so I want also a running >system >> ;-) so please give me a little hint, that I can bring my first >xfs-box up! > >In the top level Makefile for the kernel is one that is especially for >kgcc. > >You can find it including comments. Just remove the # sign from that >line. > >Cheers >Seth Hi, Bad news..... Ok, the Kernel compiled fine with kgcc ;-) and it runs longer under load then the other old kernel but i get an oops again...... :-( here it is! cu micha ksymoops 2.4.1 on i686 2.4.10-pre2-xfs. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.10-pre2-xfs/ (default) -m /boot/System.map-2.4.10-pre2-xfs (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Sep 1 19:01:03 swan kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000152 Sep 1 19:01:03 swan kernel: c01b3e95 Sep 1 19:01:03 swan kernel: *pde = 00000000 Sep 1 19:01:03 swan kernel: Oops: 0000 Sep 1 19:01:03 swan kernel: CPU: 0 Sep 1 19:01:03 swan kernel: EIP: 0010:[xlog_recover_do_inode_trans+1461/1600] Sep 1 19:01:03 swan kernel: EFLAGS: 00010246 Sep 1 19:01:03 swan kernel: eax: 00000000 ebx: ffffffe8 ecx: c1461b18 edx: c02bc7e0 Sep 1 19:01:03 swan kernel: esi: cf75a18c edi: cf5e0c00 ebp: 00000000 esp: c9a75e0c Sep 1 19:01:03 swan kernel: ds: 0018 es: 0018 ss: 0018 Sep 1 19:01:03 swan kernel: Process rm (pid: 2996, stackpage=c9a75000) Sep 1 19:01:03 swan kernel: Stack: 0000006c 00000000 cf5e0c00 00000008 c01cac0c cf5e0c00 00000000 030a3225 Sep 1 19:01:03 swan kernel: 00000000 00000000 c9a75ec4 00000000 00000000 c2172614 c21725fc 00000008 Sep 1 19:01:03 swan kernel: ce957640 c8498050 c8498042 00000084 00000000 c01d21a0 c8498000 cf5e0c00 Sep 1 19:01:03 swan kernel: Call Trace: [xfs_ioctl+3388/4528] [uiomove+192/320] [xfs_dir2_sf_toino8+704/1056] [_lsn_cmp+167/224] [_lsn_cmp+16/224] Sep 1 19:01:03 swan kernel: Code: 66 83 bb 6a 01 00 00 00 75 10 80 a3 50 01 00 00 f7 53 e8 54 Using defaults from ksymoops -t elf32-i386 -a i386 Code; 00000000 Before first symbol 00000000 <_EIP>: Code; 00000000 Before first symbol 0: 66 83 bb 6a 01 00 00 cmpw $0x0,0x16a(%ebx) Code; 00000007 Before first symbol 7: 00 Code; 00000008 Before first symbol 8: 75 10 jne 1a <_EIP+0x1a> 0000001a Before first symbol Code; 0000000a Before first symbol a: 80 a3 50 01 00 00 f7 andb $0xf7,0x150(%ebx) Code; 00000011 Before first symbol 11: 53 push %ebx Code; 00000012 Before first symbol 12: e8 54 00 00 00 call 6b <_EIP+0x6b> 0000006b Before first symbol 2 warnings issued. Results may not be reliable. ---------z44518_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM1MIICHaADAgECAgQ68WMUMA0GCSqGSIb3DQEBBAUAMIGeMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYDVQQLExdDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNz IDIgQ0EwHhcNMDEwNTAzMDAwMDAwWhcNMDIwNTAzMjM1OTAwWjCBnTELMAkGA1UE BhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgG A1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEaMBgGA1UEAxMR TWljaGFlbCBXYWhsYnJpbmsxIjAgBgkqhkiG9w0BCQEWE21pd0Bwcm9wYWNrLWRh dGEuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALIOckqT1A9Rhsfgt4Y0 A98B9yUW0jztpCFpnti1cj5hkjaB7bTj029ki6cVXwlmv/MzqrIB0AfqOhILTDOo OilUqAjydR5D88jKnLPT1JyIKOaMjjFWa26vmSB2lTp4RdPmbtkiQoUZ9cBvglMV FYL/b9gC6mEpLAAyAfV8pIrNAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAEZhuNN2 nawO0zgdlUS379E2LP1Y1UkqRvbs+JJt4o/9iICT9QtC1Xqfb2S1AUldHSrT83PW TUoNjpL+n/SYeDrq6UPkfCMrbO4XhwRcOy5b+xJG+5GfshrL0ENzBVF2SsSYWcoz cp6y0GAVI74Wf7W91QCPz4cyhr3AP7ASal15XjlXLyoNL+59AqD2elGWsU6OUCg8 qw2xG/2IYAcpMGgHpmab9OBtF4R8+2b9qnFDqWUPK+L6KjJpwPFvkYpgW4ESsW5L jQgfog9+/gB8GxFU1FXvcbnuaJFwudaq9wMyKiLWJIK0jVH5fUIUzEPOemOz8fhn zUNVTnhZVI/sF6wwggO6MIICoqADAgECAgQ5Td9zMA0GCSqGSIb3DQEBBAUAMIGe MQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYD VQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYD VQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBE YXRhIENsYXNzIDIgQ0EwHhcNMDAwNjE4MDAwMDAwWhcNMDIwNjE4MjM1OTAwWjCB njELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAG A1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEgR21iSDEgMB4G A1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sg RGF0YSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 4sC9VaqHbKulz8+2vUwsODP7NAtBFxlehMYd6zHoYgD67GKnTlQj0EKK+TtHfZvI VtPKBXo4xuwePOx34pS+yeg4Wu2Yt984UFvy5WGhaSOox5OTfQ040go0QP+GPcz/ 02q8sy/UKdEFH1Q7l4AMQoewr6mi12mSii2HudcA4oWBqshHrZG64TFbZ539M4Au DxFqxGISuozATaMw4UVzR4Jju7KUH+chhj7eTYxGr1a8Ov8xapOuSxwrR0Nm9qKl h1/b9tspuLC3wNP2SExBccmOOX1QPHI9uVOegkQX0kSFmL0kONzUIa9d9TAYyP5H /OazPHpKcb7evqyJh5gmNwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBMrCrpoVIi mshBQdBdtPVCBex75s8sb/qmPFwxTn8IHASc3AWtfBPmoEf1c5FcVUERLQFr6uQV RU5ejmJewyzzf+iKlGLjWPvWLghEibWm+GTm1rLJpe+YwgR6/5y874RhaUj3KFi7 yCJsUaF2qKgEv39Lq4VgdRihhB++ZF3zgj/dv7dwOwC2jgk8mAZf1Cp3jG8yhLnI ZIRbYOuZdUCpBzCRj1qfD+P4izFarG4sHo3k7kfkCzpsyDrCJojmXzzoF3diAm5Q PHWlYYhNA0i09m8hW9YpxhfBp7qmIIYd5tCOqjZVgiyA9RLb68a2PnS30LzIIsQH OtubyM8KT7WqAAAxgDCCAfgCAQEwgacwgZ4xCzAJBgNVBAYTAmRlMRswGQYDVQQI ExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgGA1UE ChMRUHJvcGFjayBEYXRhIEdtYkgxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSAwHgYDVQQDExdQcm9wYWNrIERhdGEgQ2xhc3MgMiBDQQIEOvFjFDAJ BgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDkwMTE2MTEzM1owIwYJKoZIhvcNAQkEMRYEFJRGiFvt3VYwK6XF wgUVHGLdd3LPMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZIhvcNAwIC AgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGAUxkzEYvy1gY9xGG0mHw8AgHF4rrzR/zMR9NeUKW0VYUuCBl/1ZlI WOPA4/Qo5+IMFX8qjZKPiB6jbnRjSq2i4xn/uOqIqY7yCKX5CaF+b9P05WbAz1VZ 7d7wBDsTk87jQv9EvvrfW/HDfQO4iErEG51y2hmYTTib93GXP5TrWoQAAAAAAAAA AA== ---------z44518_boundary_sign-- From owner-linux-xfs@oss.sgi.com Sat Sep 1 09:35:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81GZpV15201 for linux-xfs-outgoing; Sat, 1 Sep 2001 09:35:51 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81GZmd15182 for ; Sat, 1 Sep 2001 09:35:48 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id SAA10195; Sat, 1 Sep 2001 18:35:47 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id SAA22040; Sat, 1 Sep 2001 18:35:47 +0200 (CEST) Date: Sat, 1 Sep 2001 18:35:46 +0200 (CEST) From: Seth Mos To: Michael Wahlbrink cc: linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 1 Sep 2001, Michael Wahlbrink wrote: > On 31.08.2001 23:57:07 Seth Mos wrote: > >On Fri, 31 Aug 2001, Michael Wahlbrink wrote: > > Hi, > Bad news..... > Ok, the Kernel compiled fine with kgcc ;-) and it runs longer under load > then the other old kernel but i get an oops again...... :-( > here it is! I see you are using part of the syslog messages. Can you find the syslog initscript and add the -x option to it? By adding -x to syslog it will not try to interpret the oops. This might give better results in running ksymoops. I am suspecting hardware problems. Could you find and run memtest86 to test your memory? I am updating my tree here to -pre2 as well and see if it gives me problems. Cheers Seth From owner-linux-xfs@oss.sgi.com Sat Sep 1 11:14:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81IEpT16682 for linux-xfs-outgoing; Sat, 1 Sep 2001 11:14:51 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81IEld16660 for ; Sat, 1 Sep 2001 11:14:47 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f81IEe507252 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Sat, 1 Sep 2001 11:14:40 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA797770 for ; Sat, 1 Sep 2001 20:14:39 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA1957513; Sat, 1 Sep 2001 13:13:21 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA95154; Sat, 1 Sep 2001 13:13:15 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f81IBbO23125; Sat, 1 Sep 2001 13:11:37 -0500 Message-Id: <200109011811.f81IBbO23125@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: David Lloyd cc: linux-xfs@oss.sgi.com Subject: Re: Pingpong-Journaling? In-Reply-To: Message from David Lloyd of "Fri, 31 Aug 2001 11:59:30 +0930." <3B8EF68A.C3FC5FCA@rebel.net.au> Content-Transfer-Encoding: 8bit Date: Sat, 01 Sep 2001 13:11:37 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Anyone got any comments on this with respect to XFS? Well, XFS transactions do not have 'invalidation blocks' they work differently than the scheme this seems to describe. The XFS journal is also very compact since it only logs the changes to blocks rather than the whole block. Right now we do not have any plans for changing the journalling in XFS - except for getting rid of the synchronous transactions in the delete path. Steve > > DSL > > -------- Original Message -------- > Subject: [reiserfs-list] Pingpong-Journaling in reiser4? > Date: Thu, 30 Aug 2001 23:30:16 +0200 > From: Xuan Baldauf > Organization: Medium.net > To: Hans Reiser > CC: reiserfs-list@namesys.com > > Hello Hans, > > are you considering pingpong-journaling for reiser4? > > Ping-Pong journaling is that, in the case you are able to > know that the blocks you are writing to will be overwritten > due to outstanding requests|future transactions, you do not > write the invalidation block of the old transaction until > the affected blocks are overwritten by the new transaction. > Doing journaling in that way, you are bringing the count of > required writes for journaling to the count of required > writes for non-journaling (1 changed block, 1 write instead > of 1 changed block, 1 write to the journal and 1 write to > the real location), and thus saving half the > journal-related writes in the ideal case. The superblock is > a good candidate for this feature. > > I think that heavily loaded servers with parallel disk > writes will be able to see a considerable speedup. > > Xubn. From owner-linux-xfs@oss.sgi.com Sat Sep 1 11:18:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81IIrB16855 for linux-xfs-outgoing; Sat, 1 Sep 2001 11:18:53 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81IIid16833 for ; Sat, 1 Sep 2001 11:18:44 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id E202E67040; Sat, 1 Sep 2001 20:18:37 +0200 (CEST) To: Seth Mos Cc: linux-xfs@oss.sgi.com, Michael Wahlbrink Subject: Re: Kernel Oops ..... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Sat, 1 Sep 2001 20:18:36 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 01.09.2001 20:18:41, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 01.09.2001 20:18:41, Serialize complete at 01.09.2001 20:18:41, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 01.09.2001 20:18:41, S/MIME Sign complete at 01.09.2001 20:18:41, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 01.09.2001 20:18:38, Serialize complete at 01.09.2001 20:18:38 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z63867_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z63867_boundary_sign Content-Type: text/plain; charset="us-ascii" On 01.09.2001 18:35:46 Seth Mos wrote: >On Sat, 1 Sep 2001, Michael Wahlbrink wrote: > >> On 31.08.2001 23:57:07 Seth Mos wrote: >> >On Fri, 31 Aug 2001, Michael Wahlbrink wrote: >> >> Hi, >> Bad news..... >> Ok, the Kernel compiled fine with kgcc ;-) and it runs longer under >load >> then the other old kernel but i get an oops again...... :-( >> here it is! > >I see you are using part of the syslog messages. Can you find the syslog >initscript and add the -x option to it? By adding -x to syslog it will >not >try to interpret the oops. Ok its done! > >This might give better results in running ksymoops. > >I am suspecting hardware problems. Could you find and run memtest86 to >test your memory? No problem, as standard Suse Installs an Memtest Bootimage...... ..... I let run memtest for 1pass with no errors so it seems, that the 256mb infineon module works correct. Perhaps it is a problem, that i chose in the kernel athlon/duron as processor type, i'll build a kernel with only pentium.... maybe it will help? And will try the things also on another old pII mashine with only 2 30gig hdds....... (takes some time) > >I am updating my tree here to -pre2 as well and see if it gives me >problems. > >Cheers >Seth cu micha -- Michael Wahlbrink IT Services Propack Data GmbH Karlsruhe miw@propack-data.com 0721/9650-851 ---------z63867_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM1MIICHaADAgECAgQ68WMUMA0GCSqGSIb3DQEBBAUAMIGeMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYDVQQLExdDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNz IDIgQ0EwHhcNMDEwNTAzMDAwMDAwWhcNMDIwNTAzMjM1OTAwWjCBnTELMAkGA1UE BhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgG A1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEaMBgGA1UEAxMR TWljaGFlbCBXYWhsYnJpbmsxIjAgBgkqhkiG9w0BCQEWE21pd0Bwcm9wYWNrLWRh dGEuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALIOckqT1A9Rhsfgt4Y0 A98B9yUW0jztpCFpnti1cj5hkjaB7bTj029ki6cVXwlmv/MzqrIB0AfqOhILTDOo OilUqAjydR5D88jKnLPT1JyIKOaMjjFWa26vmSB2lTp4RdPmbtkiQoUZ9cBvglMV FYL/b9gC6mEpLAAyAfV8pIrNAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAEZhuNN2 nawO0zgdlUS379E2LP1Y1UkqRvbs+JJt4o/9iICT9QtC1Xqfb2S1AUldHSrT83PW TUoNjpL+n/SYeDrq6UPkfCMrbO4XhwRcOy5b+xJG+5GfshrL0ENzBVF2SsSYWcoz cp6y0GAVI74Wf7W91QCPz4cyhr3AP7ASal15XjlXLyoNL+59AqD2elGWsU6OUCg8 qw2xG/2IYAcpMGgHpmab9OBtF4R8+2b9qnFDqWUPK+L6KjJpwPFvkYpgW4ESsW5L jQgfog9+/gB8GxFU1FXvcbnuaJFwudaq9wMyKiLWJIK0jVH5fUIUzEPOemOz8fhn zUNVTnhZVI/sF6wwggO6MIICoqADAgECAgQ5Td9zMA0GCSqGSIb3DQEBBAUAMIGe MQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYD VQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYD VQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBE YXRhIENsYXNzIDIgQ0EwHhcNMDAwNjE4MDAwMDAwWhcNMDIwNjE4MjM1OTAwWjCB njELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAG A1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEgR21iSDEgMB4G A1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sg RGF0YSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 4sC9VaqHbKulz8+2vUwsODP7NAtBFxlehMYd6zHoYgD67GKnTlQj0EKK+TtHfZvI VtPKBXo4xuwePOx34pS+yeg4Wu2Yt984UFvy5WGhaSOox5OTfQ040go0QP+GPcz/ 02q8sy/UKdEFH1Q7l4AMQoewr6mi12mSii2HudcA4oWBqshHrZG64TFbZ539M4Au DxFqxGISuozATaMw4UVzR4Jju7KUH+chhj7eTYxGr1a8Ov8xapOuSxwrR0Nm9qKl h1/b9tspuLC3wNP2SExBccmOOX1QPHI9uVOegkQX0kSFmL0kONzUIa9d9TAYyP5H /OazPHpKcb7evqyJh5gmNwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBMrCrpoVIi mshBQdBdtPVCBex75s8sb/qmPFwxTn8IHASc3AWtfBPmoEf1c5FcVUERLQFr6uQV RU5ejmJewyzzf+iKlGLjWPvWLghEibWm+GTm1rLJpe+YwgR6/5y874RhaUj3KFi7 yCJsUaF2qKgEv39Lq4VgdRihhB++ZF3zgj/dv7dwOwC2jgk8mAZf1Cp3jG8yhLnI ZIRbYOuZdUCpBzCRj1qfD+P4izFarG4sHo3k7kfkCzpsyDrCJojmXzzoF3diAm5Q PHWlYYhNA0i09m8hW9YpxhfBp7qmIIYd5tCOqjZVgiyA9RLb68a2PnS30LzIIsQH OtubyM8KT7WqAAAxgDCCAfgCAQEwgacwgZ4xCzAJBgNVBAYTAmRlMRswGQYDVQQI ExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgGA1UE ChMRUHJvcGFjayBEYXRhIEdtYkgxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSAwHgYDVQQDExdQcm9wYWNrIERhdGEgQ2xhc3MgMiBDQQIEOvFjFDAJ BgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDkwMTE4MTg0MVowIwYJKoZIhvcNAQkEMRYEFEPXPs3Dzq/in1dp 4OMp49ZOFzuxMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZIhvcNAwIC AgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGAkVkLtD0KWtRhiTlgPW/FfQSUVypMlXt7IarqIEEHADdVEJTvCOYW au+dxXEFkMYi15o4WBh62cd5SS+LkBxhjcrU+GB8zFZaOTh1JU7uFc3AfITrwA4w 7cGVT26eiuma5OiyzkJInIfro/jTUBO2cngxOh8Xuf0zEphFbru9CpwAAAAAAAAA AA== ---------z63867_boundary_sign-- From owner-linux-xfs@oss.sgi.com Sat Sep 1 11:35:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81IZYF17329 for linux-xfs-outgoing; Sat, 1 Sep 2001 11:35:34 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81IZUd17310 for ; Sat, 1 Sep 2001 11:35:30 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id UAA24229; Sat, 1 Sep 2001 20:35:29 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id UAA26065; Sat, 1 Sep 2001 20:35:29 +0200 (CEST) Date: Sat, 1 Sep 2001 20:35:28 +0200 (CEST) From: Seth Mos To: Michael Wahlbrink cc: linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 1 Sep 2001, Michael Wahlbrink wrote: > On 01.09.2001 18:35:46 Seth Mos wrote: > >On Sat, 1 Sep 2001, Michael Wahlbrink wrote: > > > >> On 31.08.2001 23:57:07 Seth Mos wrote: > >> >On Fri, 31 Aug 2001, Michael Wahlbrink wrote: > >> > >> Hi, > >> Bad news..... > >> Ok, the Kernel compiled fine with kgcc ;-) and it runs longer under > >load > >> then the other old kernel but i get an oops again...... :-( > >> here it is! > > > >I see you are using part of the syslog messages. Can you find the syslog > >initscript and add the -x option to it? By adding -x to syslog it will > >not > >try to interpret the oops. > > Ok its done! > > > > >This might give better results in running ksymoops. > > > >I am suspecting hardware problems. Could you find and run memtest86 to > >test your memory? > > No problem, as standard Suse Installs an Memtest Bootimage...... Nice. > ..... I let run memtest for 1pass with no errors so it seems, that the > 256mb infineon module works correct. > Perhaps it is a problem, that i chose in the kernel athlon/duron as > processor type, i'll build a kernel with only pentium.... maybe it will > help? It could affect, compiling for i386 will always work, but compiling for athlon/duron will make it faster. I compile my kernel for athlon systems and I don't have problems. Do you have the latest bios for your system, that is asuming you have a motherboard with a VIA chipset. > And will try the things also on another old pII mashine with only 2 30gig > hdds....... (takes some time) If can try it on another machine we can see if it is purely a software or hardware problem. Cheers Seth From owner-linux-xfs@oss.sgi.com Sat Sep 1 11:38:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81IcDG17479 for linux-xfs-outgoing; Sat, 1 Sep 2001 11:38:13 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81Ic5d17460; Sat, 1 Sep 2001 11:38:05 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id C751B67040; Sat, 1 Sep 2001 20:37:58 +0200 (CEST) To: "Michael Wahlbrink" Cc: Seth Mos , linux-xfs@oss.sgi.com, Michael Wahlbrink , owner-linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Sat, 1 Sep 2001 20:37:58 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 01.09.2001 20:38:02, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 01.09.2001 20:38:02, Serialize complete at 01.09.2001 20:38:02, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 01.09.2001 20:38:02, S/MIME Sign complete at 01.09.2001 20:38:02, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 01.09.2001 20:37:59, Serialize complete at 01.09.2001 20:37:59 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z61674_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z61674_boundary_sign Content-Type: text/plain; charset="us-ascii" On 01.09.2001 20:18:36 "Michael Wahlbrink" wrote: >On 01.09.2001 18:35:46 Seth Mos wrote: [...] >>I see you are using part of the syslog messages. Can you find the >syslog >>initscript and add the -x option to it? By adding -x to syslog it will >>not >>try to interpret the oops. > >Ok its done! But no my syslog doesnt start anymore its complainig about an unknown option -x ;-( > >> cu micha ---------z61674_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM1MIICHaADAgECAgQ68WMUMA0GCSqGSIb3DQEBBAUAMIGeMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYDVQQLExdDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNz IDIgQ0EwHhcNMDEwNTAzMDAwMDAwWhcNMDIwNTAzMjM1OTAwWjCBnTELMAkGA1UE BhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgG A1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEaMBgGA1UEAxMR TWljaGFlbCBXYWhsYnJpbmsxIjAgBgkqhkiG9w0BCQEWE21pd0Bwcm9wYWNrLWRh dGEuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALIOckqT1A9Rhsfgt4Y0 A98B9yUW0jztpCFpnti1cj5hkjaB7bTj029ki6cVXwlmv/MzqrIB0AfqOhILTDOo OilUqAjydR5D88jKnLPT1JyIKOaMjjFWa26vmSB2lTp4RdPmbtkiQoUZ9cBvglMV FYL/b9gC6mEpLAAyAfV8pIrNAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAEZhuNN2 nawO0zgdlUS379E2LP1Y1UkqRvbs+JJt4o/9iICT9QtC1Xqfb2S1AUldHSrT83PW TUoNjpL+n/SYeDrq6UPkfCMrbO4XhwRcOy5b+xJG+5GfshrL0ENzBVF2SsSYWcoz cp6y0GAVI74Wf7W91QCPz4cyhr3AP7ASal15XjlXLyoNL+59AqD2elGWsU6OUCg8 qw2xG/2IYAcpMGgHpmab9OBtF4R8+2b9qnFDqWUPK+L6KjJpwPFvkYpgW4ESsW5L jQgfog9+/gB8GxFU1FXvcbnuaJFwudaq9wMyKiLWJIK0jVH5fUIUzEPOemOz8fhn zUNVTnhZVI/sF6wwggO6MIICoqADAgECAgQ5Td9zMA0GCSqGSIb3DQEBBAUAMIGe MQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYD VQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYD VQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBE YXRhIENsYXNzIDIgQ0EwHhcNMDAwNjE4MDAwMDAwWhcNMDIwNjE4MjM1OTAwWjCB njELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAG A1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEgR21iSDEgMB4G A1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sg RGF0YSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 4sC9VaqHbKulz8+2vUwsODP7NAtBFxlehMYd6zHoYgD67GKnTlQj0EKK+TtHfZvI VtPKBXo4xuwePOx34pS+yeg4Wu2Yt984UFvy5WGhaSOox5OTfQ040go0QP+GPcz/ 02q8sy/UKdEFH1Q7l4AMQoewr6mi12mSii2HudcA4oWBqshHrZG64TFbZ539M4Au DxFqxGISuozATaMw4UVzR4Jju7KUH+chhj7eTYxGr1a8Ov8xapOuSxwrR0Nm9qKl h1/b9tspuLC3wNP2SExBccmOOX1QPHI9uVOegkQX0kSFmL0kONzUIa9d9TAYyP5H /OazPHpKcb7evqyJh5gmNwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBMrCrpoVIi mshBQdBdtPVCBex75s8sb/qmPFwxTn8IHASc3AWtfBPmoEf1c5FcVUERLQFr6uQV RU5ejmJewyzzf+iKlGLjWPvWLghEibWm+GTm1rLJpe+YwgR6/5y874RhaUj3KFi7 yCJsUaF2qKgEv39Lq4VgdRihhB++ZF3zgj/dv7dwOwC2jgk8mAZf1Cp3jG8yhLnI ZIRbYOuZdUCpBzCRj1qfD+P4izFarG4sHo3k7kfkCzpsyDrCJojmXzzoF3diAm5Q PHWlYYhNA0i09m8hW9YpxhfBp7qmIIYd5tCOqjZVgiyA9RLb68a2PnS30LzIIsQH OtubyM8KT7WqAAAxgDCCAfgCAQEwgacwgZ4xCzAJBgNVBAYTAmRlMRswGQYDVQQI ExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgGA1UE ChMRUHJvcGFjayBEYXRhIEdtYkgxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSAwHgYDVQQDExdQcm9wYWNrIERhdGEgQ2xhc3MgMiBDQQIEOvFjFDAJ BgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDkwMTE4MzgwMlowIwYJKoZIhvcNAQkEMRYEFGu8kOB6bjK7RFZh Xs4qFnq+9KQRMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZIhvcNAwIC AgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGAhPZWDhB436a+KDuFEMk6/jL4NYjMZcMsj3csywhZEAxlYjnudg1i vz1K/TI8z8ILDyf7dTgC1FbuI9Z+L209dFy5xn6iFtPsrld7MqzRyXM7elrFzZHc Khs3vXOtAPf36ByqFZF/bFk95c60vOWj8g9UAd9niCLInHRpYZoLdsAAAAAAAAAA AA== ---------z61674_boundary_sign-- From owner-linux-xfs@oss.sgi.com Sat Sep 1 11:44:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81Iise17658 for linux-xfs-outgoing; Sat, 1 Sep 2001 11:44:54 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81Iind17638; Sat, 1 Sep 2001 11:44:50 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id UAA25063; Sat, 1 Sep 2001 20:44:48 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id UAA26355; Sat, 1 Sep 2001 20:44:48 +0200 (CEST) Date: Sat, 1 Sep 2001 20:44:48 +0200 (CEST) From: Seth Mos To: Michael Wahlbrink cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 1 Sep 2001, Michael Wahlbrink wrote: > On 01.09.2001 20:18:36 "Michael Wahlbrink" wrote: > >On 01.09.2001 18:35:46 Seth Mos wrote: > [...] > >>I see you are using part of the syslog messages. Can you find the > >syslog > >>initscript and add the -x option to it? By adding -x to syslog it will > >>not > >>try to interpret the oops. > > > >Ok its done! > > But no my syslog doesnt start anymore its complainig about an unknown > option -x ;-( Oops! It seems that this is not supported under SuSE. It might be that SuSE uses another deamon for syslog. Ok skip that part. From owner-linux-xfs@oss.sgi.com Sat Sep 1 11:45:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81Ij6B17740 for linux-xfs-outgoing; Sat, 1 Sep 2001 11:45:06 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81Iixd17711 for ; Sat, 1 Sep 2001 11:44:59 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id BB49F67040; Sat, 1 Sep 2001 20:44:52 +0200 (CEST) To: Seth Mos Cc: linux-xfs@oss.sgi.com, Michael Wahlbrink Subject: Re: Kernel Oops ..... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Sat, 1 Sep 2001 20:44:51 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 01.09.2001 20:44:56, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 01.09.2001 20:44:56, Serialize complete at 01.09.2001 20:44:56, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 01.09.2001 20:44:56, S/MIME Sign complete at 01.09.2001 20:44:56, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 01.09.2001 20:44:53, Serialize complete at 01.09.2001 20:44:53 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z49578_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z49578_boundary_sign Content-Type: text/plain; charset="us-ascii" On 01.09.2001 20:35:28 Seth Mos wrote: > >It could affect, compiling for i386 will always work, but compiling for >athlon/duron will make it faster. I compile my kernel for athlon systems >and I don't have problems. Do you have the latest bios for your system, >that is asuming you have a motherboard with a VIA chipset. > No, Its one with the new SiS735 (ECS K7S5A)....... But I'll see if there is a new bios..... >> And will try the things also on another old pII mashine with only 2 >30gig >> hdds....... (takes some time) > >If can try it on another machine we can see if it is purely a software >or >hardware problem. It's on the way cu michael ---------z49578_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM1MIICHaADAgECAgQ68WMUMA0GCSqGSIb3DQEBBAUAMIGeMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYDVQQLExdDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNz IDIgQ0EwHhcNMDEwNTAzMDAwMDAwWhcNMDIwNTAzMjM1OTAwWjCBnTELMAkGA1UE BhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgG A1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEaMBgGA1UEAxMR TWljaGFlbCBXYWhsYnJpbmsxIjAgBgkqhkiG9w0BCQEWE21pd0Bwcm9wYWNrLWRh dGEuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALIOckqT1A9Rhsfgt4Y0 A98B9yUW0jztpCFpnti1cj5hkjaB7bTj029ki6cVXwlmv/MzqrIB0AfqOhILTDOo OilUqAjydR5D88jKnLPT1JyIKOaMjjFWa26vmSB2lTp4RdPmbtkiQoUZ9cBvglMV FYL/b9gC6mEpLAAyAfV8pIrNAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAEZhuNN2 nawO0zgdlUS379E2LP1Y1UkqRvbs+JJt4o/9iICT9QtC1Xqfb2S1AUldHSrT83PW TUoNjpL+n/SYeDrq6UPkfCMrbO4XhwRcOy5b+xJG+5GfshrL0ENzBVF2SsSYWcoz cp6y0GAVI74Wf7W91QCPz4cyhr3AP7ASal15XjlXLyoNL+59AqD2elGWsU6OUCg8 qw2xG/2IYAcpMGgHpmab9OBtF4R8+2b9qnFDqWUPK+L6KjJpwPFvkYpgW4ESsW5L jQgfog9+/gB8GxFU1FXvcbnuaJFwudaq9wMyKiLWJIK0jVH5fUIUzEPOemOz8fhn zUNVTnhZVI/sF6wwggO6MIICoqADAgECAgQ5Td9zMA0GCSqGSIb3DQEBBAUAMIGe MQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYD VQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYD VQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBE YXRhIENsYXNzIDIgQ0EwHhcNMDAwNjE4MDAwMDAwWhcNMDIwNjE4MjM1OTAwWjCB njELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAG A1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEgR21iSDEgMB4G A1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sg RGF0YSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 4sC9VaqHbKulz8+2vUwsODP7NAtBFxlehMYd6zHoYgD67GKnTlQj0EKK+TtHfZvI VtPKBXo4xuwePOx34pS+yeg4Wu2Yt984UFvy5WGhaSOox5OTfQ040go0QP+GPcz/ 02q8sy/UKdEFH1Q7l4AMQoewr6mi12mSii2HudcA4oWBqshHrZG64TFbZ539M4Au DxFqxGISuozATaMw4UVzR4Jju7KUH+chhj7eTYxGr1a8Ov8xapOuSxwrR0Nm9qKl h1/b9tspuLC3wNP2SExBccmOOX1QPHI9uVOegkQX0kSFmL0kONzUIa9d9TAYyP5H /OazPHpKcb7evqyJh5gmNwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBMrCrpoVIi mshBQdBdtPVCBex75s8sb/qmPFwxTn8IHASc3AWtfBPmoEf1c5FcVUERLQFr6uQV RU5ejmJewyzzf+iKlGLjWPvWLghEibWm+GTm1rLJpe+YwgR6/5y874RhaUj3KFi7 yCJsUaF2qKgEv39Lq4VgdRihhB++ZF3zgj/dv7dwOwC2jgk8mAZf1Cp3jG8yhLnI ZIRbYOuZdUCpBzCRj1qfD+P4izFarG4sHo3k7kfkCzpsyDrCJojmXzzoF3diAm5Q PHWlYYhNA0i09m8hW9YpxhfBp7qmIIYd5tCOqjZVgiyA9RLb68a2PnS30LzIIsQH OtubyM8KT7WqAAAxgDCCAfgCAQEwgacwgZ4xCzAJBgNVBAYTAmRlMRswGQYDVQQI ExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgGA1UE ChMRUHJvcGFjayBEYXRhIEdtYkgxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSAwHgYDVQQDExdQcm9wYWNrIERhdGEgQ2xhc3MgMiBDQQIEOvFjFDAJ BgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDkwMTE4NDQ1NlowIwYJKoZIhvcNAQkEMRYEFAkQswJRS3UlXij/ vX0Mav4oTYdBMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZIhvcNAwIC AgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGAl1d4L7sJID4ImOcD+Wc7UhU1D9c0LndFToS8VEtpbpRrsmWS4ndu atHS+VckrVHW6EH5Ut6dOoVueTVvfL1/wON4KsGfTf2oN8FxK7/qg8zoVs6C09xf 5mFd7+5bMe4AXd7/629bUgEu8BPwv86q7VtPLsrDxddKY4sD7w5Tx9oAAAAAAAAA AA== ---------z49578_boundary_sign-- From owner-linux-xfs@oss.sgi.com Sat Sep 1 12:24:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81JOCH18428 for linux-xfs-outgoing; Sat, 1 Sep 2001 12:24:12 -0700 Received: from monkeyiq.dnsalias.org (CPE-203-45-215-234.qld.bigpond.net.au [203.45.215.234]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81JO9d18409 for ; Sat, 1 Sep 2001 12:24:09 -0700 Received: by monkeyiq.dnsalias.org id f81IrdM31005 ; Sun, 2 Sep 2001 04:53:39 +1000 Date: Sun, 2 Sep 2001 04:53:39 +1000 Message-Id: <200109011853.f81IrdM31005@monkeyiq.dnsalias.org> To: linux-xfs@oss.sgi.com Cc: monkeyiq@users.sourceforge.net Subject: Preallocation of space From: monkeyiq MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I was reading over this again: http://www.osnews.com/story.php?news_id=69 And decided that the next feature for ferris to pick on was: It's an extent-based filesystem, has features like delayed allocation, space preallocation and space coallescing on deletion, and goes to great lengths in attempting to layout files using the largest extents possible (an "extent" being an offset and a length within a file). So I was reading xfs_mkfile.c line 188 of 277 flck.l_whence = SEEK_SET; flck.l_start = 0LL; flck.l_len = size; #if 0 (void)ioctl(fd, XFS_IOC_RESVSP64, &flck); I presume that this XFS_IOC_RESVSP64 tells XFS to reserve off a chunk of space for future use by the file. Are the ioctl() calls for XFS documented anywhere? /usr/include/xfs/xfs_fs.h and the tool src is all I am using at the moment. It just struck me as odd that in xfsprogs-1.2.8 the call was preprocessed out. ----------------------------------------------------- http://witme.sourceforge.net/libferris.web/index.html From owner-linux-xfs@oss.sgi.com Sat Sep 1 12:53:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81JrDK18903 for linux-xfs-outgoing; Sat, 1 Sep 2001 12:53:13 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81JrAd18882 for ; Sat, 1 Sep 2001 12:53:11 -0700 Received: (qmail 5747 invoked from network); 1 Sep 2001 19:53:06 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 1 Sep 2001 19:53:06 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Michael Wahlbrink" cc: Seth Mos , linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... In-reply-to: Your message of "Sat, 01 Sep 2001 20:37:58 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 02 Sep 2001 05:53:06 +1000 Message-ID: <22084.999373986@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 1 Sep 2001 20:37:58 +0200, "Michael Wahlbrink" wrote: >But no my syslog doesnt start anymore its complainig about an unknown >option -x ;-( klogd -x, not syslog -x. From owner-linux-xfs@oss.sgi.com Sat Sep 1 13:08:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81K8N819208 for linux-xfs-outgoing; Sat, 1 Sep 2001 13:08:23 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81K8Gd19186 for ; Sat, 1 Sep 2001 13:08:17 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 941CB67040; Sat, 1 Sep 2001 22:08:10 +0200 (CEST) To: Keith Owens Cc: Seth Mos , linux-xfs@oss.sgi.com, "Michael Wahlbrink" Subject: Re: Kernel Oops ..... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Sat, 1 Sep 2001 22:08:08 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 01.09.2001 22:08:13, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 01.09.2001 22:08:13, Serialize complete at 01.09.2001 22:08:13, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 01.09.2001 22:08:13, S/MIME Sign complete at 01.09.2001 22:08:13, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 01.09.2001 22:08:10, Serialize complete at 01.09.2001 22:08:10 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z116_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z116_boundary_sign Content-Type: text/plain; charset="us-ascii" On 01.09.2001 21:53:06 Keith Owens wrote: >On Sat, 1 Sep 2001 20:37:58 +0200, >"Michael Wahlbrink" wrote: >>But no my syslog doesnt start anymore its complainig about an unknown >>option -x ;-( > >klogd -x, not syslog -x. Thanks, that works ;-) cu micha ---------z116_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM1MIICHaADAgECAgQ68WMUMA0GCSqGSIb3DQEBBAUAMIGeMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYDVQQLExdDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNz IDIgQ0EwHhcNMDEwNTAzMDAwMDAwWhcNMDIwNTAzMjM1OTAwWjCBnTELMAkGA1UE BhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgG A1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEaMBgGA1UEAxMR TWljaGFlbCBXYWhsYnJpbmsxIjAgBgkqhkiG9w0BCQEWE21pd0Bwcm9wYWNrLWRh dGEuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALIOckqT1A9Rhsfgt4Y0 A98B9yUW0jztpCFpnti1cj5hkjaB7bTj029ki6cVXwlmv/MzqrIB0AfqOhILTDOo OilUqAjydR5D88jKnLPT1JyIKOaMjjFWa26vmSB2lTp4RdPmbtkiQoUZ9cBvglMV FYL/b9gC6mEpLAAyAfV8pIrNAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAEZhuNN2 nawO0zgdlUS379E2LP1Y1UkqRvbs+JJt4o/9iICT9QtC1Xqfb2S1AUldHSrT83PW TUoNjpL+n/SYeDrq6UPkfCMrbO4XhwRcOy5b+xJG+5GfshrL0ENzBVF2SsSYWcoz cp6y0GAVI74Wf7W91QCPz4cyhr3AP7ASal15XjlXLyoNL+59AqD2elGWsU6OUCg8 qw2xG/2IYAcpMGgHpmab9OBtF4R8+2b9qnFDqWUPK+L6KjJpwPFvkYpgW4ESsW5L jQgfog9+/gB8GxFU1FXvcbnuaJFwudaq9wMyKiLWJIK0jVH5fUIUzEPOemOz8fhn zUNVTnhZVI/sF6wwggO6MIICoqADAgECAgQ5Td9zMA0GCSqGSIb3DQEBBAUAMIGe MQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYD VQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYD VQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBE YXRhIENsYXNzIDIgQ0EwHhcNMDAwNjE4MDAwMDAwWhcNMDIwNjE4MjM1OTAwWjCB njELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAG A1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEgR21iSDEgMB4G A1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sg RGF0YSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 4sC9VaqHbKulz8+2vUwsODP7NAtBFxlehMYd6zHoYgD67GKnTlQj0EKK+TtHfZvI VtPKBXo4xuwePOx34pS+yeg4Wu2Yt984UFvy5WGhaSOox5OTfQ040go0QP+GPcz/ 02q8sy/UKdEFH1Q7l4AMQoewr6mi12mSii2HudcA4oWBqshHrZG64TFbZ539M4Au DxFqxGISuozATaMw4UVzR4Jju7KUH+chhj7eTYxGr1a8Ov8xapOuSxwrR0Nm9qKl h1/b9tspuLC3wNP2SExBccmOOX1QPHI9uVOegkQX0kSFmL0kONzUIa9d9TAYyP5H /OazPHpKcb7evqyJh5gmNwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBMrCrpoVIi mshBQdBdtPVCBex75s8sb/qmPFwxTn8IHASc3AWtfBPmoEf1c5FcVUERLQFr6uQV RU5ejmJewyzzf+iKlGLjWPvWLghEibWm+GTm1rLJpe+YwgR6/5y874RhaUj3KFi7 yCJsUaF2qKgEv39Lq4VgdRihhB++ZF3zgj/dv7dwOwC2jgk8mAZf1Cp3jG8yhLnI ZIRbYOuZdUCpBzCRj1qfD+P4izFarG4sHo3k7kfkCzpsyDrCJojmXzzoF3diAm5Q PHWlYYhNA0i09m8hW9YpxhfBp7qmIIYd5tCOqjZVgiyA9RLb68a2PnS30LzIIsQH OtubyM8KT7WqAAAxgDCCAfgCAQEwgacwgZ4xCzAJBgNVBAYTAmRlMRswGQYDVQQI ExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgGA1UE ChMRUHJvcGFjayBEYXRhIEdtYkgxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSAwHgYDVQQDExdQcm9wYWNrIERhdGEgQ2xhc3MgMiBDQQIEOvFjFDAJ BgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDkwMTIwMDgxM1owIwYJKoZIhvcNAQkEMRYEFCkxcyOx1GqBi8G0 qdleSTALTe3CMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZIhvcNAwIC AgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGAr2gxXO5u9lQu0xGEdQxVdv6veR/xyZ4Ck9M1hGfSTj9c9lXhSKrr Wqv+ZEoX7VcBlUWNKEdXP9gTJQ+PIWkYKNobct0/ibtyOCyM/St0mK+mNMa0oFQz z11ekluWQpvYIEPsWLS5TCnvR8CvYcB0b+SkfQGEVPjiUXMlOEJ0Y78AAAAAAAAA AA== ---------z116_boundary_sign-- From owner-linux-xfs@oss.sgi.com Sat Sep 1 14:36:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81La4820509 for linux-xfs-outgoing; Sat, 1 Sep 2001 14:36:04 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81LZxd20490; Sat, 1 Sep 2001 14:36:00 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA10572; Sat, 1 Sep 2001 23:35:57 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA03063; Sat, 1 Sep 2001 23:35:57 +0200 (CEST) Date: Sat, 1 Sep 2001 23:35:57 +0200 (CEST) From: Seth Mos To: Keith Owens cc: Michael Wahlbrink , linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... In-Reply-To: <22084.999373986@ocs3.ocs-net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 2 Sep 2001, Keith Owens wrote: > On Sat, 1 Sep 2001 20:37:58 +0200, > "Michael Wahlbrink" wrote: > >But no my syslog doesnt start anymore its complainig about an unknown > >option -x ;-( > > klogd -x, not syslog -x. Uhm, yes ... does almost right count ? From owner-linux-xfs@oss.sgi.com Sat Sep 1 14:42:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81LgLu20691 for linux-xfs-outgoing; Sat, 1 Sep 2001 14:42:21 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81Lg9d20669; Sat, 1 Sep 2001 14:42:09 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 872D667040; Sat, 1 Sep 2001 23:42:01 +0200 (CEST) To: "Michael Wahlbrink" Cc: Keith Owens , Seth Mos , linux-xfs@oss.sgi.com, "Michael Wahlbrink" , owner-linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Sat, 1 Sep 2001 23:42:00 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 01.09.2001 23:42:05, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 01.09.2001 23:42:05, Serialize complete at 01.09.2001 23:42:05, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 01.09.2001 23:42:05, S/MIME Sign complete at 01.09.2001 23:42:05, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 01.09.2001 23:42:02, Serialize complete at 01.09.2001 23:42:02 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z31063_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z31063_boundary_sign Content-Type: text/plain; charset="us-ascii" On 01.09.2001 22:08:08 "Michael Wahlbrink" wrote: >On 01.09.2001 21:53:06 Keith Owens wrote: >>On Sat, 1 Sep 2001 20:37:58 +0200, >>"Michael Wahlbrink" wrote: >>>But no my syslog doesnt start anymore its complainig about an unknown >>>option -x ;-( >> >>klogd -x, not syslog -x. > >Thanks, that works ;-) And here comes the next oops with newest bios and -x for klogd :-( cu michael ksymoops 2.4.1 on i686 2.4.10-pre2-xfs. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.10-pre2-xfs/ (default) -m /boot/System.map-2.4.10-pre2-xfs (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Sep 2 00:29:43 swan kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000152 Sep 2 00:29:43 swan kernel: c01b3e95 Sep 2 00:29:43 swan kernel: *pde = 00000000 Sep 2 00:29:43 swan kernel: Oops: 0000 Sep 2 00:29:43 swan kernel: CPU: 0 Sep 2 00:29:43 swan kernel: EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Sep 2 00:29:43 swan kernel: EFLAGS: 00010246 Sep 2 00:29:43 swan kernel: eax: 00000000 ebx: ffffffe8 ecx: c147cc50 edx: c02bc7e0 Sep 2 00:29:43 swan kernel: esi: c8858ecc edi: cf5f7c00 ebp: 00000000 esp: cf4f7e0c Sep 2 00:29:43 swan kernel: ds: 0018 es: 0018 ss: 0018 Sep 2 00:29:43 swan kernel: Process rm (pid: 1019, stackpage=cf4f7000) Sep 2 00:29:43 swan kernel: Stack: 00000000 00000000 cf5f7c00 00000008 c01cac0c cf5f7c00 00000000 0a0ac689 Sep 2 00:29:43 swan kernel: 00000000 00000000 cf4f7ec4 00000000 00000000 cacd426c cacd4254 00000008 Sep 2 00:29:43 swan kernel: cc4f66c0 cf5fc078 cf5fc06a 0000002a 00000000 c01d21a0 cf5fc000 cf5f7c00 Sep 2 00:29:43 swan kernel: Call Trace: [] [] [] [] [] Sep 2 00:29:43 swan kernel: [] [] [] [] [] [] Sep 2 00:29:43 swan kernel: [] [] [] Sep 2 00:29:43 swan kernel: Code: 66 83 bb 6a 01 00 00 00 75 10 80 a3 50 01 00 00 f7 53 e8 54 >>EIP; c01b3e95 <===== Trace; c01cac0c Trace; c01d21a0 Trace; c019f090 Trace; c01cf6c7 Trace; c01cf630 Trace; c01cf630 Trace; c01d8f7d Trace; c01416cc Trace; c01cf630 Trace; c01396b3 Trace; c0139d5b Trace; c013a33c <__user_walk+3c/60> Trace; c0137486 Trace; c0106cab Code; c01b3e95 00000000 <_EIP>: Code; c01b3e95 <===== 0: 66 83 bb 6a 01 00 00 cmpw $0x0,0x16a(%ebx) <===== Code; c01b3e9c 7: 00 Code; c01b3e9d 8: 75 10 jne 1a <_EIP+0x1a> c01b3eaf Code; c01b3e9f a: 80 a3 50 01 00 00 f7 andb $0xf7,0x150(%ebx) Code; c01b3ea6 11: 53 push %ebx Code; c01b3ea7 12: e8 54 00 00 00 call 6b <_EIP+0x6b> c01b3f00 2 warnings issued. Results may not be reliable. ---------z31063_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM1MIICHaADAgECAgQ68WMUMA0GCSqGSIb3DQEBBAUAMIGeMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYDVQQLExdDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNz IDIgQ0EwHhcNMDEwNTAzMDAwMDAwWhcNMDIwNTAzMjM1OTAwWjCBnTELMAkGA1UE BhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgG A1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEaMBgGA1UEAxMR TWljaGFlbCBXYWhsYnJpbmsxIjAgBgkqhkiG9w0BCQEWE21pd0Bwcm9wYWNrLWRh dGEuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALIOckqT1A9Rhsfgt4Y0 A98B9yUW0jztpCFpnti1cj5hkjaB7bTj029ki6cVXwlmv/MzqrIB0AfqOhILTDOo OilUqAjydR5D88jKnLPT1JyIKOaMjjFWa26vmSB2lTp4RdPmbtkiQoUZ9cBvglMV FYL/b9gC6mEpLAAyAfV8pIrNAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAEZhuNN2 nawO0zgdlUS379E2LP1Y1UkqRvbs+JJt4o/9iICT9QtC1Xqfb2S1AUldHSrT83PW TUoNjpL+n/SYeDrq6UPkfCMrbO4XhwRcOy5b+xJG+5GfshrL0ENzBVF2SsSYWcoz cp6y0GAVI74Wf7W91QCPz4cyhr3AP7ASal15XjlXLyoNL+59AqD2elGWsU6OUCg8 qw2xG/2IYAcpMGgHpmab9OBtF4R8+2b9qnFDqWUPK+L6KjJpwPFvkYpgW4ESsW5L jQgfog9+/gB8GxFU1FXvcbnuaJFwudaq9wMyKiLWJIK0jVH5fUIUzEPOemOz8fhn zUNVTnhZVI/sF6wwggO6MIICoqADAgECAgQ5Td9zMA0GCSqGSIb3DQEBBAUAMIGe MQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYD VQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYD VQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBE YXRhIENsYXNzIDIgQ0EwHhcNMDAwNjE4MDAwMDAwWhcNMDIwNjE4MjM1OTAwWjCB njELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAG A1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEgR21iSDEgMB4G A1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sg RGF0YSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 4sC9VaqHbKulz8+2vUwsODP7NAtBFxlehMYd6zHoYgD67GKnTlQj0EKK+TtHfZvI VtPKBXo4xuwePOx34pS+yeg4Wu2Yt984UFvy5WGhaSOox5OTfQ040go0QP+GPcz/ 02q8sy/UKdEFH1Q7l4AMQoewr6mi12mSii2HudcA4oWBqshHrZG64TFbZ539M4Au DxFqxGISuozATaMw4UVzR4Jju7KUH+chhj7eTYxGr1a8Ov8xapOuSxwrR0Nm9qKl h1/b9tspuLC3wNP2SExBccmOOX1QPHI9uVOegkQX0kSFmL0kONzUIa9d9TAYyP5H /OazPHpKcb7evqyJh5gmNwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBMrCrpoVIi mshBQdBdtPVCBex75s8sb/qmPFwxTn8IHASc3AWtfBPmoEf1c5FcVUERLQFr6uQV RU5ejmJewyzzf+iKlGLjWPvWLghEibWm+GTm1rLJpe+YwgR6/5y874RhaUj3KFi7 yCJsUaF2qKgEv39Lq4VgdRihhB++ZF3zgj/dv7dwOwC2jgk8mAZf1Cp3jG8yhLnI ZIRbYOuZdUCpBzCRj1qfD+P4izFarG4sHo3k7kfkCzpsyDrCJojmXzzoF3diAm5Q PHWlYYhNA0i09m8hW9YpxhfBp7qmIIYd5tCOqjZVgiyA9RLb68a2PnS30LzIIsQH OtubyM8KT7WqAAAxgDCCAfgCAQEwgacwgZ4xCzAJBgNVBAYTAmRlMRswGQYDVQQI ExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgGA1UE ChMRUHJvcGFjayBEYXRhIEdtYkgxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSAwHgYDVQQDExdQcm9wYWNrIERhdGEgQ2xhc3MgMiBDQQIEOvFjFDAJ BgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDkwMTIxNDIwNVowIwYJKoZIhvcNAQkEMRYEFAeiH2LnHkD5n9OC 2LgjhS/yQ0DSMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZIhvcNAwIC AgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGAsHpuAAA+sbcHZH1XQ4nojNIfQzg4pt+e1BzG2a/Ne8zxGQyLAZdm KLYFw5NUQPgxsJLQ7oSM1u7manVHWnzoe83dHT11b7yx+ng4hqSpt+Tb3f9kGQVI g/fT+pwq8YFuLDsrOUARFSEjymFOo61fxLISNci8U0gbIg0BMzmPFf4AAAAAAAAA AA== ---------z31063_boundary_sign-- From owner-linux-xfs@oss.sgi.com Sat Sep 1 14:50:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81LoWf20926 for linux-xfs-outgoing; Sat, 1 Sep 2001 14:50:32 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81LoRd20904; Sat, 1 Sep 2001 14:50:28 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA11957; Sat, 1 Sep 2001 23:50:26 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA03721; Sat, 1 Sep 2001 23:50:26 +0200 (CEST) Date: Sat, 1 Sep 2001 23:50:26 +0200 (CEST) From: Seth Mos To: Michael Wahlbrink cc: Keith Owens , linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 1 Sep 2001, Michael Wahlbrink wrote: > On 01.09.2001 22:08:08 "Michael Wahlbrink" wrote: > >On 01.09.2001 21:53:06 Keith Owens wrote: > >>On Sat, 1 Sep 2001 20:37:58 +0200, > >>"Michael Wahlbrink" wrote: > >>>But no my syslog doesnt start anymore its complainig about an unknown > >>>option -x ;-( > >> > >>klogd -x, not syslog -x. > > > >Thanks, that works ;-) > > And here comes the next oops with newest bios and -x for klogd :-( You are first that I see with a SiS 735 based motherboard so I have no clue how well it works within Linux. The performance and stability of this board is reported to be good. So I am assuming it works decently under linux as well. Do you have problems with a normal ext2 filesystem or a linus kernel? You will have to wait for a guru te repond to the Oops and do something with it, which is something I can't Cheers Seth From owner-linux-xfs@oss.sgi.com Sat Sep 1 15:07:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f81M7xk21304 for linux-xfs-outgoing; Sat, 1 Sep 2001 15:07:59 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f81M7pd21281 for ; Sat, 1 Sep 2001 15:07:51 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id B26BF67040; Sun, 2 Sep 2001 00:07:43 +0200 (CEST) To: Seth Mos Cc: Keith Owens , linux-xfs@oss.sgi.com, Michael Wahlbrink Subject: Re: Kernel Oops ..... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Sun, 2 Sep 2001 00:07:42 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 02.09.2001 00:07:47, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 02.09.2001 00:07:47, Serialize complete at 02.09.2001 00:07:47, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 02.09.2001 00:07:48, S/MIME Sign complete at 02.09.2001 00:07:48, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 02.09.2001 00:07:48, Serialize complete at 02.09.2001 00:07:48, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 02.09.2001 00:07:44, Serialize complete at 02.09.2001 00:07:44 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z43558_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z43558_boundary_sign Content-Type: text/plain; charset="us-ascii" On 01.09.2001 23:50:26 Seth Mos wrote: >On Sat, 1 Sep 2001, Michael Wahlbrink wrote: > >> On 01.09.2001 22:08:08 "Michael Wahlbrink" wrote: >> >On 01.09.2001 21:53:06 Keith Owens wrote: >> >>On Sat, 1 Sep 2001 20:37:58 +0200, >> >>"Michael Wahlbrink" wrote: >> >>>But no my syslog doesnt start anymore its complainig about an >unknown >> >>>option -x ;-( >> >> >> >>klogd -x, not syslog -x. >> > >> >Thanks, that works ;-) >> >> And here comes the next oops with newest bios and -x for klogd :-( > >You are first that I see with a SiS 735 based motherboard so I have no >clue how well it works within Linux. The performance and stability of >this >board is reported to be good. So I am assuming it works decently under >linux as well. Do you have problems with a normal ext2 filesystem or a >linus kernel? > >You will have to wait for a guru te repond to the Oops and do something >with it, which is something I can't > Ok, no problem ;-) I'll make my tests with ext2 to see if the kernel 'oopses' too......... And the PII is still compiling th xfs kernel.... cu michael ---------z43558_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM1MIICHaADAgECAgQ68WMUMA0GCSqGSIb3DQEBBAUAMIGeMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYDVQQLExdDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNz IDIgQ0EwHhcNMDEwNTAzMDAwMDAwWhcNMDIwNTAzMjM1OTAwWjCBnTELMAkGA1UE BhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgG A1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEaMBgGA1UEAxMR TWljaGFlbCBXYWhsYnJpbmsxIjAgBgkqhkiG9w0BCQEWE21pd0Bwcm9wYWNrLWRh dGEuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALIOckqT1A9Rhsfgt4Y0 A98B9yUW0jztpCFpnti1cj5hkjaB7bTj029ki6cVXwlmv/MzqrIB0AfqOhILTDOo OilUqAjydR5D88jKnLPT1JyIKOaMjjFWa26vmSB2lTp4RdPmbtkiQoUZ9cBvglMV FYL/b9gC6mEpLAAyAfV8pIrNAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAEZhuNN2 nawO0zgdlUS379E2LP1Y1UkqRvbs+JJt4o/9iICT9QtC1Xqfb2S1AUldHSrT83PW TUoNjpL+n/SYeDrq6UPkfCMrbO4XhwRcOy5b+xJG+5GfshrL0ENzBVF2SsSYWcoz cp6y0GAVI74Wf7W91QCPz4cyhr3AP7ASal15XjlXLyoNL+59AqD2elGWsU6OUCg8 qw2xG/2IYAcpMGgHpmab9OBtF4R8+2b9qnFDqWUPK+L6KjJpwPFvkYpgW4ESsW5L jQgfog9+/gB8GxFU1FXvcbnuaJFwudaq9wMyKiLWJIK0jVH5fUIUzEPOemOz8fhn zUNVTnhZVI/sF6wwggO6MIICoqADAgECAgQ5Td9zMA0GCSqGSIb3DQEBBAUAMIGe MQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYD VQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYD VQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBE YXRhIENsYXNzIDIgQ0EwHhcNMDAwNjE4MDAwMDAwWhcNMDIwNjE4MjM1OTAwWjCB njELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAG A1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEgR21iSDEgMB4G A1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sg RGF0YSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 4sC9VaqHbKulz8+2vUwsODP7NAtBFxlehMYd6zHoYgD67GKnTlQj0EKK+TtHfZvI VtPKBXo4xuwePOx34pS+yeg4Wu2Yt984UFvy5WGhaSOox5OTfQ040go0QP+GPcz/ 02q8sy/UKdEFH1Q7l4AMQoewr6mi12mSii2HudcA4oWBqshHrZG64TFbZ539M4Au DxFqxGISuozATaMw4UVzR4Jju7KUH+chhj7eTYxGr1a8Ov8xapOuSxwrR0Nm9qKl h1/b9tspuLC3wNP2SExBccmOOX1QPHI9uVOegkQX0kSFmL0kONzUIa9d9TAYyP5H /OazPHpKcb7evqyJh5gmNwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBMrCrpoVIi mshBQdBdtPVCBex75s8sb/qmPFwxTn8IHASc3AWtfBPmoEf1c5FcVUERLQFr6uQV RU5ejmJewyzzf+iKlGLjWPvWLghEibWm+GTm1rLJpe+YwgR6/5y874RhaUj3KFi7 yCJsUaF2qKgEv39Lq4VgdRihhB++ZF3zgj/dv7dwOwC2jgk8mAZf1Cp3jG8yhLnI ZIRbYOuZdUCpBzCRj1qfD+P4izFarG4sHo3k7kfkCzpsyDrCJojmXzzoF3diAm5Q PHWlYYhNA0i09m8hW9YpxhfBp7qmIIYd5tCOqjZVgiyA9RLb68a2PnS30LzIIsQH OtubyM8KT7WqAAAxgDCCAfgCAQEwgacwgZ4xCzAJBgNVBAYTAmRlMRswGQYDVQQI ExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgGA1UE ChMRUHJvcGFjayBEYXRhIEdtYkgxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSAwHgYDVQQDExdQcm9wYWNrIERhdGEgQ2xhc3MgMiBDQQIEOvFjFDAJ BgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDkwMTIyMDc0N1owIwYJKoZIhvcNAQkEMRYEFGQHBFLafrPL9m2L yBjCg9rQ1esCMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZIhvcNAwIC AgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGAeJTk4ngP9C3gjFCpQp/hxJUk+04IFrS9hYufDrMv11a/XI1ntrnq qdY8eP3SBHVj+YqCP205WBUhDoBGfb5i/JDhH/ZVVR3ES4NSbwG/0x59sb0umKA9 udL+MRiyQkJCHlTPaSAWn3padqJiTLhrSb2KS1gXmVe4Y5tZhBQUfSUAAAAAAAAA AA== ---------z43558_boundary_sign-- From owner-linux-xfs@oss.sgi.com Sun Sep 2 13:11:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f82KBcZ08645 for linux-xfs-outgoing; Sun, 2 Sep 2001 13:11:38 -0700 Received: from kendy.up.ac.za (kendy.up.ac.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f82KBOd08626 for ; Sun, 2 Sep 2001 13:11:34 -0700 Received: from [137.215.145.210] (helo=it.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 15ddZ8-0000FK-00; Sun, 02 Sep 2001 22:09:58 +0200 Message-ID: <3B929216.B2D4AC60@it.up.ac.za> Date: Sun, 02 Sep 2001 22:09:58 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: "Theo E. Schlossnagle" CC: exim-users@exim.org, linux-xfs@oss.sgi.com Subject: Re: Exim and XFS filesystem References: <3B8BB7C7.4020808@omniti.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *15ddZ8-0000FK-00*dXniCV7KWOg* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk What mount options did you use ? Paul "Theo E. Schlossnagle" wrote: > Hello all, > > We have been running exim for a while and we run it on over 75 machines > (Linux, BSDs Solaris). We recently started using SGI's xfs filesystem for > most of our operations because of its speed and stability -- we are _very_ > happy with it. I have never had any problems with it ... until now. > > Exim v3.14,v3.22,v3.33 and Linux 2.4.2-xfs. The xfs parition in question is > running atop a RAID-1 md device on two 9GB scsi drives. > > After running Exim with its spool directory on an xfs partition and under low > load (100 messages/minute) I would soon get an Exim process spinning CPU bound > and I could not kill it [kill -9 did nothing]. The system was stuck on disk > writes (so any process that calls fsync or friends would get stuck in the run > queue never to come out again.) No modified files were writted to disk (by > any process) after this point. A reboot was required and restore "normal" > operation. > > We tried many things to fix this with no success, but as soon as we configured > exim to use a non xfs (ext2 in this case) mounted spool directory, the problem > instantly disappeared. > > It looked as if the kernel had a thread stuck writing to or reading from the > filesystem journal. If anyone knows a solution to this problem, I am all > ears. Otherwise, steer clear of running you Exim spools on xfs. > > -- > Theo Schlossnagle > 1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984 > 2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7 From owner-linux-xfs@oss.sgi.com Sun Sep 2 13:43:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f82Kh6V09268 for linux-xfs-outgoing; Sun, 2 Sep 2001 13:43:06 -0700 Received: from kendy.up.ac.za (kendy.up.ac.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f82Kh0d09246 for ; Sun, 2 Sep 2001 13:43:01 -0700 Received: from [137.215.145.210] (helo=it.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 15de46-0000jQ-00; Sun, 02 Sep 2001 22:41:58 +0200 Message-ID: <3B929996.FFC809B9@it.up.ac.za> Date: Sun, 02 Sep 2001 22:41:58 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: Eric Sandeen , XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *15de46-0000jQ-00*RAJGVXPGfF6* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > On Fri, 31 Aug 2001, Eric Sandeen wrote: > > > Paul Schutte wrote: > > > > > > Hi, > > > > > > I found a problem while doing benchmarks with mongo.pl > > > > > > The sympthom is that the machine just hangs. No error messages. > > > > Ok, I see this too.... looks like bdflush is the only thing that's > > running. > > > > If I try a sync, then that's what hangs, both of these get lost in > > write_some_buffers - looks like a deadlock? > > Then it is specific to scsi perhaps. AFAIk the scsi layer was never > considered "elegant". I Think this is a SCSI thing. I just ran it on a BusLogic card. I saw the same sympthoms: only bdflush running. Thus far I could'nt reproduce this on any IDE system. > > > Hm.... you think Hans did this on purpose? ;-) > > > > I'll see if I can find anything next week... time for my weekend now, > > I'm afraid. > > Mine started 8 hours ago :-) > > > Thanks for pointing this out! > > > > -Eric > > > > p.s. fwiw, this is on adaptec hardware as well. > > I am not seeing it on my Athlon and IDE home box. Is this thus only > reproducable on adaptec/scsi hardware? > > I'll scavenge the room for my spare 4.5GB scsi disk and see if I can get > my homebox to hang. My controller however is a sym53c8xx. > > I have tried 1,5 and 10 processes but it just won't hang :-) > > Cheers > > Seth Paul From owner-linux-xfs@oss.sgi.com Sun Sep 2 16:17:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f82NHit11349 for linux-xfs-outgoing; Sun, 2 Sep 2001 16:17:44 -0700 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f82NHfd11330 for ; Sun, 2 Sep 2001 16:17:41 -0700 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Sun, 2 Sep 2001 18:16:53 -0500 Message-ID: <85063BBE668FD411944400D0B744267A88851B@AUSMAIL> From: "Gonyou, Austin" To: XFS mailing list Subject: System lock while accessing files causes file corruption Date: Sun, 2 Sep 2001 18:16:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Why is this? If I open a file, text/otherwise and the power actually fails, (i turn it off), once in a while I get a corrupt file. Why is this? What would happen if I was writing to some Oracle filesystems and this situation occurred? Please advise. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com From owner-linux-xfs@oss.sgi.com Sun Sep 2 16:51:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f82Np1811916 for linux-xfs-outgoing; Sun, 2 Sep 2001 16:51:01 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f82Nowd11897 for ; Sun, 2 Sep 2001 16:50:58 -0700 Received: from rattle.melbourne.sgi.com (rattle.melbourne.sgi.com [134.14.55.145]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA05403 for ; Sun, 2 Sep 2001 16:49:18 -0700 (PDT) mail_from (kenmcd@melbourne.sgi.com) Received: from localhost (kenmcd@localhost) by rattle.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA91626; Mon, 3 Sep 2001 10:48:23 +1100 (AEDT) X-Authentication-Warning: rattle.melbourne.sgi.com: kenmcd owned process doing -bs Date: Mon, 3 Sep 2001 10:48:23 +1100 From: Ken McDonell Reply-To: To: "Gonyou, Austin" cc: XFS mailing list Subject: Re: System lock while accessing files causes file corruption In-Reply-To: <85063BBE668FD411944400D0B744267A88851B@AUSMAIL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I think this has been done to death on the list and FAQ. XFS journals metadata, not file data. In the case of Oracle, that's what the transaction log is for, and that is why the transaction log for a DBMS requires synchronous or guaranteed writes. On Sun, 2 Sep 2001, Gonyou, Austin wrote: > Why is this? If I open a file, text/otherwise and the power actually fails, > (i turn it off), once in a while I get a corrupt file. Why is this? What > would happen if I was writing to some Oracle filesystems and this situation > occurred? Please advise. > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-796-9023 > email: austin@coremetrics.com > From owner-linux-xfs@oss.sgi.com Sun Sep 2 17:18:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f830IfD12373 for linux-xfs-outgoing; Sun, 2 Sep 2001 17:18:41 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f830Icd12350 for ; Sun, 2 Sep 2001 17:18:39 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id CAA20477; Mon, 3 Sep 2001 02:18:34 +0200 (CEST) Message-Id: <4.3.2.7.2.20010903021638.034ee5e0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Sep 2001 02:17:53 +0200 To: "Gonyou, Austin" , XFS mailing list From: Seth Mos Subject: Re: System lock while accessing files causes file corruption In-Reply-To: <85063BBE668FD411944400D0B744267A88851B@AUSMAIL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 18:16 2-9-2001 -0500, Gonyou, Austin wrote: >Why is this? If I open a file, text/otherwise and the power actually fails, >(i turn it off), once in a while I get a corrupt file. Why is this? What >would happen if I was writing to some Oracle filesystems and this situation >occurred? Please advise. See the http://oss.sgi.com/projects/xfs/faq.html#nulls A database would survive since most have their own buffering and transaction scheme. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sun Sep 2 19:03:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8323A313791 for linux-xfs-outgoing; Sun, 2 Sep 2001 19:03:10 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83233d13772 for ; Sun, 2 Sep 2001 19:03:03 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA00214 for ; Sun, 2 Sep 2001 19:01:22 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id MAA30179; Mon, 3 Sep 2001 12:02:13 +1000 Date: Mon, 3 Sep 2001 12:02:13 +1000 From: Keith Owens Message-Id: <200109030202.MAA30179@sherman.melbourne.sgi.com> Subject: TAKE - Update to 2.4.10-pre4 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Update to 2.4.10-pre4 Date: Sun Sep 2 18:59:58 PDT 2001 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102058a linux/scripts/ver_linux - 1.9 linux/mm/vmscan.c - 1.72 linux/mm/swapfile.c - 1.35 linux/mm/swap_state.c - 1.28 linux/mm/memory.c - 1.57 linux/mm/filemap.c - 1.84 linux/kernel/sched.c - 1.39 linux/kernel/ksyms.c - 1.103 linux/kernel/fork.c - 1.34 linux/include/linux/sysv_fs.h - 1.11 linux/include/linux/skbuff.h - 1.21 linux/include/linux/sched.h - 1.42 linux/include/linux/pagemap.h - 1.28 linux/include/linux/fs.h - 1.114 linux/include/asm-ppc/machdep.h - 1.18 linux/include/asm-ppc/keyboard.h - 1.10 linux/include/asm-i386/timex.h - 1.4 linux/include/asm-i386/system.h - 1.19 linux/include/asm-i386/msr.h - 1.9 linux/fs/umsdos/rdir.c - 1.13 linux/fs/umsdos/namei.c - 1.11 linux/fs/umsdos/inode.c - 1.17 linux/fs/umsdos/emd.c - 1.9 linux/fs/umsdos/dir.c - 1.17 linux/fs/umsdos/README-WIP.txt - 1.4 linux/fs/sysv/symlink.c - 1.7 linux/fs/sysv/inode.c - 1.23 linux/fs/sysv/balloc.c - 1.6 linux/fs/sysv/Makefile - 1.6 linux/fs/namei.c - 1.35 linux/fs/binfmt_elf.c - 1.30 linux/fs/Makefile - 1.34 linux/drivers/usb/Makefile - 1.41 linux/drivers/usb/Config.in - 1.45 linux/drivers/scsi/sd.c - 1.40 linux/drivers/pci/pci.c - 1.42 linux/drivers/net/Makefile - 1.45 linux/drivers/macintosh/via-pmu.c - 1.15 linux/drivers/macintosh/Makefile - 1.10 linux/drivers/char/Makefile - 1.47 linux/drivers/block/ps2esdi.c - 1.18 linux/drivers/block/loop.c - 1.34 linux/arch/sparc64/kernel/ioctl32.c - 1.40 linux/arch/ppc/kernel/prep_setup.c - 1.23 linux/arch/ppc/kernel/pmac_setup.c - 1.24 linux/arch/ppc/kernel/chrp_setup.c - 1.25 linux/arch/ppc/8xx_io/fec.c - 1.14 linux/arch/ppc/8xx_io/enet.c - 1.14 linux/arch/i386/kernel/setup.c - 1.50 linux/arch/i386/kernel/mtrr.c - 1.27 linux/arch/i386/defconfig - 1.65 linux/Makefile - 1.117 linux/Documentation/Configure.help - 1.96 linux/drivers/video/vga16fb.c - 1.10 linux/drivers/usb/printer.c - 1.39 linux/drivers/block/blkpg.c - 1.9 linux/drivers/block/cpqarray.c - 1.25 linux/drivers/net/macsonic.c - 1.8 linux/include/asm-i386/hw_irq.h - 1.19 linux/arch/ppc/kernel/head_8xx.S - 1.13 linux/drivers/block/DAC960.c - 1.33 linux/arch/i386/kernel/pci-pc.c - 1.25 linux/include/linux/pmu.h - 1.4 linux/drivers/pcmcia/yenta.c - 1.27 linux/drivers/net/8139too.c - 1.25 linux/drivers/usb/plusb.c - 1.13 linux/drivers/ide/ide.c - 1.26 linux/arch/mips64/kernel/ioctl32.c - 1.8 linux/arch/i386/kdb/kdbasupport.c - 1.16 linux/drivers/usb/storage/transport.c - 1.11 linux/include/asm-sparc/kmap_types.h - 1.3 linux/drivers/usb/storage/sddr09.c - 1.8 linux/drivers/md/raid1.c - 1.12 linux/arch/i386/kernel/bluesmoke.c - 1.11 linux/drivers/block/cciss.c - 1.12 linux/drivers/md/md.c - 1.19 linux/include/asm-ppc/kmap_types.h - 1.5 linux/fs/reiserfs/stree.c - 1.6 linux/fs/reiserfs/super.c - 1.6 linux/fs/reiserfs/journal.c - 1.6 linux/fs/reiserfs/inode.c - 1.8 linux/fs/reiserfs/bitmap.c - 1.3 linux/drivers/usb/storage/unusual_devs.h - 1.5 linux/drivers/net/wan/dscc4.c - 1.3 linux/fs/freevxfs/vxfs_super.c - 1.3 linux/fs/freevxfs/vxfs_olt.c - 1.2 linux/fs/freevxfs/vxfs_inode.c - 1.4 linux/fs/freevxfs/vxfs_fshead.c - 1.2 linux/fs/freevxfs/vxfs_extern.h - 1.2 linux/drivers/acpi/ospm/busmgr/Makefile - 1.2 linux/drivers/acpi/include/platform/acgcc.h - 1.2 linux/fs/sysv/super.c - 1.2 From owner-linux-xfs@oss.sgi.com Sun Sep 2 21:46:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f834k1d15686 for linux-xfs-outgoing; Sun, 2 Sep 2001 21:46:01 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f834jvd15667 for ; Sun, 2 Sep 2001 21:45:57 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id AAA12948; Mon, 3 Sep 2001 00:38:12 -0400 Message-ID: <3B930B7F.372CB436@ieee.org> Date: Mon, 03 Sep 2001 00:47:59 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: XFS mailing list Subject: Best CVS tags to build from ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've probably asked this before, but I'm having trouble finding the answer in my old E-mails, the archives or in a downloaded CVS tree myself. Q: Is there a moving CVS tag or series of tags that is/are "STABLE" or otherwise that are used to mark potential patch or other potential points of release? Alt-Q: If not, would someone let me know whenever they feel there is a good tag and/or date-timestamp of the tree when it would be good to build RPMs from? Thanx in advance ... -- TheBS P.S. The reason why I ask is because I'm going to try to start releasing kernel RPMs again. My current job function (wireless LAN development) will require me to do kernel modifications and releases for various distros anyway, so I figure I might as well release an XFS version (since it is currently my preferred 2.4 kernel JFS after exhausted use of it, ReiserFS and Ext3 over the past year). P.S.S. I'm working hard to find a SDSL provider for here in Central Florida so I can serve out more than my current 256Kbps site. I know the lines are capable, but only ADSL seems to be offered by the relatively ignorant salespeople I can get ahold of. Does anyone know of one offering SDSL? I'm willing to pay several hundred $$$/month for a 768Kbps - 1.5Mbps SDSL line with high or unlimited transfers to a residential (or commercial if I have to) area. Thanx again. -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com From owner-linux-xfs@oss.sgi.com Sun Sep 2 22:13:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f835Djs16102 for linux-xfs-outgoing; Sun, 2 Sep 2001 22:13:45 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f835Dhd16082 for ; Sun, 2 Sep 2001 22:13:43 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA04023 for ; Sun, 2 Sep 2001 22:12:03 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA43483; Mon, 3 Sep 2001 16:10:47 +1100 (EDT) Date: Mon, 3 Sep 2001 16:10:47 +1100 From: Timothy Shimmin To: Andrew Klaassen Cc: linux-xfs@oss.sgi.com Subject: Re: Problems with DAT tape.... Message-ID: <20010903161046.O135568@boing.melbourne.sgi.com> References: <002501c12fea$b1091620$50824e40@iboats.com> <20010829103705.H114864@boing.melbourne.sgi.com> <20010829102702.B7083@dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20010829102702.B7083@dkp.com>; from ak@dkp.com on Wed, Aug 29, 2001 at 10:27:02AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Aug 29, 2001 at 10:27:02AM -0400, Andrew Klaassen wrote: > On Wed, Aug 29, 2001 at 10:37:05AM +1100, > Timothy Shimmin wrote: > > > I would recommend just putting the scsi tape driver into > > variable block sized mode. > > > > # mt -f /dev/st0 setblk 0 > > We've found that doing this on certain tape drives - especially > when you're trying to read the data back - can lead to pretty > significant slowdowns. So you might want to do a little testing > in your particular environment before you go ahead and do > this... > Thanks for the tip. --Tim From owner-linux-xfs@oss.sgi.com Sun Sep 2 22:42:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f835gJj16636 for linux-xfs-outgoing; Sun, 2 Sep 2001 22:42:19 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f835gHd16617 for ; Sun, 2 Sep 2001 22:42:17 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f835gB507550 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Sun, 2 Sep 2001 22:42:11 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id HAA821574 for ; Mon, 3 Sep 2001 07:42:08 +0200 (CEST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id PAA05707; Mon, 3 Sep 2001 15:42:02 +1000 Date: Mon, 3 Sep 2001 15:42:02 +1000 From: Keith Owens Message-Id: <200109030542.PAA05707@sherman.melbourne.sgi.com> Subject: TAKE - Correct 2.4.10-pre4 for UP APIC Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk 2.4.10-pre4 has a partial copy of the UP APIC code from the -ac tree, but not all of it. NOTE: kdb for Linus's tree and for XFS will not work on Athlon with CONFIG_X86_UP_IOAPIC. The full fix for Athlon UP is only in the -ac tree. Do not use CONFIG_X86_UP_IOAPIC on Athlon UP in XFS. Date: Sun Sep 2 22:39:03 PDT 2001 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102063a linux/arch/i386/kernel/apic.c - 1.18 From owner-linux-xfs@oss.sgi.com Sun Sep 2 23:30:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f836UgH17480 for linux-xfs-outgoing; Sun, 2 Sep 2001 23:30:42 -0700 Received: from rebel.net.au (IDENT:root@mail.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f836Udd17461 for ; Sun, 2 Sep 2001 23:30:39 -0700 Received: from rebel.net.au (dialup-6.rebel.net.au [203.20.69.76]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id QAA31222 for ; Mon, 3 Sep 2001 16:00:32 +0930 Message-ID: <3B93250B.79CE6C23@rebel.net.au> Date: Mon, 03 Sep 2001 16:06:59 +0930 From: David Lloyd X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS Minus the Journal Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Weird question, and I could probably just "try", but is there any way to use XFS without the journal? DSL -- Pussy's good for six at the most (Mrs. Lovett, Sweeney Todd) From owner-linux-xfs@oss.sgi.com Mon Sep 3 00:23:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f837NRN18177 for linux-xfs-outgoing; Mon, 3 Sep 2001 00:23:27 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f837NOd18158 for ; Mon, 3 Sep 2001 00:23:24 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f837NI511152 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Mon, 3 Sep 2001 00:23:18 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id JAA818794 for ; Mon, 3 Sep 2001 09:23:18 +0200 (CEST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA20654 for linux-xfs@oss.sgi.com; Mon, 3 Sep 2001 17:21:57 +1000 (EST) Date: Mon, 3 Sep 2001 17:21:57 +1000 (EST) From: Nathan Scott Message-Id: <200109030721.RAA20654@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Couple of minor fixes for recently reported issues. Date: Mon Sep 3 00:18:05 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102065a cmd/xfsprogs/db/freesp.c - 1.2 - do the same thing as db/check.c in the situation where we can't read a block in a btree - warn, then continue, don't segv. cmd/xfsprogs/mkfile/xfs_mkfile.c - 1.5 - looks like the prealloc ioctl is all there in the kernel, but this bit of user code was not updated to use it (conditional via -p). fix that. cmd/xfsprogs/doc/CHANGES - 1.35 - update with a couple of minor changes. From owner-linux-xfs@oss.sgi.com Mon Sep 3 00:25:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f837Puf18309 for linux-xfs-outgoing; Mon, 3 Sep 2001 00:25:56 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f837Pld18290 for ; Mon, 3 Sep 2001 00:25:48 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id f837Pg511314 for ; Mon, 3 Sep 2001 00:25:42 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA22597; Mon, 3 Sep 2001 18:24:25 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA18315; Mon, 3 Sep 2001 18:24:24 +1100 (AEDT) Date: Mon, 3 Sep 2001 18:24:24 +1100 From: Nathan Scott To: Fran?ois Dupoux Cc: linux-xfs@oss.sgi.com Subject: Re: segfault in xfsprogs/xfs_db Message-ID: <20010903182424.D15451@wobbly.melbourne.sgi.com> References: <01082721164700.00907@duron750.fdupoux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01082721164700.00907@duron750.fdupoux.org>; from fdupoux@free.fr on Mon, Aug 27, 2001 at 09:16:47PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, I just put a fix in for the core dump here - db/freesp.c now does the same thing as db/check.c when it can't read one of the blocks in a btree. as to why it can't, I'm not sure yet, but at least now we'll be able to see which block and which allocation group the problem is, and it will attempt to keep going instead of dying. thanks. On Mon, Aug 27, 2001 at 09:16:47PM +0200, Fran?ois Dupoux wrote: > Hi, > > I had a segfault with xfs_db compiled from xfsprogs-1.3.5.src.tar.gz. > Kernel 2.4.9, Redhat-7.1 > > The segfault happens when I run the command "freesp -d -s" with "xfs_db -x > /dev/hdc5". > This partition was formatted by mkfs.xfs. This is a 14.16 GB partition, > with 5.34 GB used. > > duron750:/home/dupoux# xfs_db -x /dev/hdc5 > xfs_db: freesp -d -s > 0 43730 1 > 0 43731 1 > 0 43732 1 > 0 43733 1 > 0 43734 1 > 0 43735 1 > Segmentation fault (core dumped) > > --------------- gdb /sbin/xfs_db core ------------------- > GNU gdb 5.0rh-5 Red Hat Linux 7.1 > Copyright 2001 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-redhat-linux"... > Core was generated by `xfs_db -x /dev/hdc5'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /lib/i686/libc.so.6...done. > Loaded symbols for /lib/i686/libc.so.6 > Reading symbols from /lib/ld-linux.so.2...done. > Loaded symbols for /lib/ld-linux.so.2 > #0 scanfunc_bno (ablock=0x0, typ=TYP_BNOBT, level=0, agf=0x80ab5e0) at > /usr/include/linux/byteorder/swab.h:132 > 132 { > -------------------------------------------------------- > > ------------ informations about /dev/hdc5 ------------- > Block size....................4096 bytes > Total blocks count............3710999 > Used blocks count.............1400933 > Free blocks count.............2310066 > Space usage:..................37 % > Total space:..................14.16 GB > Used space....................5.34 GB > Free space....................8.81 GB > Bitmap size...................453.00 KB > Allocation Group count:.......15 > Blocks per Allocation Group...262144 > Allocation Group size:........1.00 GB > -------------------------------------------------------- > > You can download the core file from http://www.partimage.org/misc/core.gz > It seems that the "freelist" is working, and it segfault at beginning of > reading > the btree (the BNO one). > > Here is the beginning of the result I d'like to obtain: > --------------------------------------------------------- > addToHist: 0 43730 1 > addToHist: 0 43731 1 > addToHist: 0 43732 1 > addToHist: 0 43733 1 > addToHist: 0 43734 1 > addToHist: 0 43735 1 > addToHist: 0 12 1 > addToHist: 0 54 247 > addToHist: 0 325 89 > addToHist: 0 566 25 > addToHist: 0 628 821 > addToHist: 0 1465 11 > addToHist: 0 1813 159 > addToHist: 0 1976 1 > ...... > --------------------------------------------------------- > > The partition was very fragmented. There is no problem when reading files > from the mount point. (I am using the patch XFS-2001-08-19 for 2.4.9). Here > is how > I made this 14 GB partition: > mkfs.xfs /dev/hdc5 > mount /dev/hdc5 /mnt/ess > cd /mnt/ess > createdata -d6 . > mv a r > mv b s > createdata -d6 . > umount /mnt/ess > > createdata is a small program which creates a lot of files of a random size, > with random data. It > fills the partition. When there is no space left, it erases a lot of files > (it keeps 1 file for 6 files > when the option -d6 is used). It's very useful to make a fragmented file > system. You can download the source > code on http://www.partimage.org/misc/createdata.cpp. > > I already had the same problem, after formatting and filling this partition > with the same method (other random files) > > thanks > -- Nathan From owner-linux-xfs@oss.sgi.com Mon Sep 3 00:28:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f837SsL18471 for linux-xfs-outgoing; Mon, 3 Sep 2001 00:28:54 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f837Spd18452 for ; Mon, 3 Sep 2001 00:28:51 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id f837SjJ07368 for ; Mon, 3 Sep 2001 00:28:45 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA22617; Mon, 3 Sep 2001 18:27:23 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA94602; Mon, 3 Sep 2001 18:27:23 +1100 (AEDT) Date: Mon, 3 Sep 2001 18:27:23 +1100 From: Nathan Scott To: monkeyiq Cc: linux-xfs@oss.sgi.com Subject: Re: Standard EA names Message-ID: <20010903182723.E15451@wobbly.melbourne.sgi.com> References: <200109010420.f814KhY32589@monkeyiq.dnsalias.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200109010420.f814KhY32589@monkeyiq.dnsalias.org>; from monkeyiq@users.sourceforge.net on Sat, Sep 01, 2001 at 02:20:43PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Sat, Sep 01, 2001 at 02:20:43PM +1000, monkeyiq wrote: > > Hi, > I am creating a VFS solution that relies on EA to a heavy degree. > I am wondering if there is a EA naming convention forum out there? Not that I know of. For the extended attributes that XFS uses itself (ie. in the "root" namespace, not the "user" namespace), the naming convention is to use "SGI_" as the name prefix. This is used for things like ACLs, MAC labels, DMAPI attributes, and several others. > For example, the GPG guys might decide what the attr name of a sig > block should be? I will probably make up names myself using something > like the emacs-naming-scheme that I have been using for read only > generated EA so far in ferris. Just thought I'd ask incase there was > already an effort in place for shared naming of handy attributes. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Sep 3 00:36:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f837aQa18727 for linux-xfs-outgoing; Mon, 3 Sep 2001 00:36:26 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f837aMd18707 for ; Mon, 3 Sep 2001 00:36:22 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id AAA01356 for ; Mon, 3 Sep 2001 00:36:17 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA22655; Mon, 3 Sep 2001 18:34:57 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA68177; Mon, 3 Sep 2001 18:34:56 +1100 (AEDT) Date: Mon, 3 Sep 2001 18:34:55 +1100 From: Nathan Scott To: monkeyiq Cc: linux-xfs@oss.sgi.com Subject: Re: Preallocation of space Message-ID: <20010903183455.F15451@wobbly.melbourne.sgi.com> References: <200109011853.f81IrdM31005@monkeyiq.dnsalias.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200109011853.f81IrdM31005@monkeyiq.dnsalias.org>; from monkeyiq@users.sourceforge.net on Sun, Sep 02, 2001 at 04:53:39AM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Sun, Sep 02, 2001 at 04:53:39AM +1000, monkeyiq wrote: > > I was reading over this again: > http://www.osnews.com/story.php?news_id=69 > ... > It's an extent-based filesystem, has features like delayed allocation, > space preallocation and space coallescing on deletion, and goes to > great lengths in attempting to layout files using the largest extents > possible (an "extent" being an offset and a length within a file). Pfft - don't listen to that guy! > > So I was reading xfs_mkfile.c line 188 of 277 > flck.l_whence = SEEK_SET; > flck.l_start = 0LL; > flck.l_len = size; > #if 0 > (void)ioctl(fd, XFS_IOC_RESVSP64, &flck); > Hmm.... well I see the kernel code is all there. I'm guessing this was just overlooked during porting, so I've pushed in the change (mkfile does prealloc conditionally only, via the -p option). > I presume that this XFS_IOC_RESVSP64 tells XFS to reserve off a chunk of > space for future use by the file. Yes, pretty much. > Are the ioctl() calls for XFS documented anywhere? No, but they should be. Some of the documentation exists in the IRIX syssgi man page - I'll probably slap that into xfs(5) at some point. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Sep 3 00:54:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f837spQ19234 for linux-xfs-outgoing; Mon, 3 Sep 2001 00:54:51 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f837smd19215 for ; Mon, 3 Sep 2001 00:54:48 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id AAA07199 for ; Mon, 3 Sep 2001 00:53:09 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA22741; Mon, 3 Sep 2001 18:52:05 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA90876; Mon, 3 Sep 2001 18:52:05 +1100 (AEDT) Date: Mon, 3 Sep 2001 18:52:05 +1100 From: Nathan Scott To: David Lloyd Cc: linux-xfs@oss.sgi.com Subject: Re: XFS Minus the Journal Message-ID: <20010903185205.G15451@wobbly.melbourne.sgi.com> References: <3B93250B.79CE6C23@rebel.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B93250B.79CE6C23@rebel.net.au>; from lloy0076@rebel.net.au on Mon, Sep 03, 2001 at 04:06:59PM +0930 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Mon, Sep 03, 2001 at 04:06:59PM +0930, David Lloyd wrote: > > Weird question, and I could probably just "try", but is there any way to > use XFS without the journal? No. There was a plan to do this (via a new mount option, IIRC) awhile ago to compare performance to non-journaled filesystems, but noone ever got around to it. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Sep 3 02:08:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8398Xh20943 for linux-xfs-outgoing; Mon, 3 Sep 2001 02:08:33 -0700 Received: from monkeyiq.dnsalias.org (CPE-203-45-215-234.qld.bigpond.net.au [203.45.215.234]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8398Sd20924 for ; Mon, 3 Sep 2001 02:08:28 -0700 Received: by monkeyiq.dnsalias.org id f83988S26342 ; Mon, 3 Sep 2001 19:08:08 +1000 Date: Mon, 3 Sep 2001 19:08:08 +1000 Message-Id: <200109030908.f83988S26342@monkeyiq.dnsalias.org> To: Nathan Scott Cc: monkeyiq , linux-xfs@oss.sgi.com Subject: Re: Preallocation of space From: monkeyiq MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan Scott writes: > hi, > > On Sun, Sep 02, 2001 at 04:53:39AM +1000, monkeyiq wrote: > > > > So I was reading xfs_mkfile.c line 188 of 277 > > flck.l_whence = SEEK_SET; > > flck.l_start = 0LL; > > flck.l_len = size; > > #if 0 > > (void)ioctl(fd, XFS_IOC_RESVSP64, &flck); > > > > Hmm.... well I see the kernel code is all there. I'm > guessing this was just overlooked during porting, so I've > pushed in the change (mkfile does prealloc conditionally > only, via the -p option). > > > I presume that this XFS_IOC_RESVSP64 tells XFS to reserve off a chunk of > > space for future use by the file. > > Yes, pretty much. > > > Are the ioctl() calls for XFS documented anywhere? > > No, but they should be. Some of the documentation exists in > the IRIX syssgi man page - I'll probably slap that into xfs(5) > at some point. I've found this page which I'll use as my reference to syssgi() unless there is a better online version. http://reality.sgi.com/cgi-bin/getman?syssgi-2#toc1 One interesting question about this call, if I have a file (potentially with holes in it) that is, for example, 4Mb large and issue a SEEK_SET, start=0, len=10Mb should this ioctl work? Or is reserving space only valid from the end of file? From the above interface it would seem that one can reserve space from anywhere, eg, SEEK_CUR, start=1Mb, len=4Mb to reserve a 4 meg chunk one meg down the pipe. I would like to know when its best for this call to be made, I am thinking as a extra param to file creation in ferris, though I might also allow one to perform it at any time so that a file can be extended with preallocation when a new chunk of data is known to be coming and will be put into that file. ----------------------------------------------------- A new world order: http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Mon Sep 3 05:02:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83C2Sx23964 for linux-xfs-outgoing; Mon, 3 Sep 2001 05:02:28 -0700 Received: from wingate.merck.de (wingate.merck.de [155.250.128.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83C2Nd23944 for ; Mon, 3 Sep 2001 05:02:24 -0700 Received: from dedamsg4.merck.de (mail4.merck.de [155.250.249.26]) by wingate.merck.de (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id OAA07908 for ; Mon, 3 Sep 2001 14:02:21 +0200 (METDST) From: Oliver.Karch@merck.de Received: from admin.bci.merck.de ([155.250.217.66]) by dedamsg4.merck.de (Lotus Domino Release 5.0.8) with ESMTP id 2001090314022028:47457 ; Mon, 3 Sep 2001 14:02:20 +0200 Received: from mailserver.bci.merck.de (gate-ranseti.bci.merck.de [155.250.217.8]) by admin.bci.merck.de (8.8.5/8.7.1) with ESMTP id OAA7929505; Mon, 3 Sep 2001 14:02:19 +0200 (MDT) Message-ID: <3B93714A.55B0A38D@mailserver.bci.merck.de> Date: Mon, 03 Sep 2001 14:02:19 +0200 Organization: Merck KGaA X-Mailer: Mozilla 4.61C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Cc: BCIHelp@admin.bci.merck.de.sgi.com X-MIMETrack: Itemize by SMTP Server on DEDAMSG4/EMD/Merck(Release 5.0.8 |June 18, 2001) at 03.09.2001 14:02:20, Serialize by Router on DEDAMSG4/EMD/Merck(Release 5.0.8 |June 18, 2001) at 03.09.2001 14:02:21, Serialize complete at 03.09.2001 14:02:21 Subject: Value too large for defined data type Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, we are successfully using xfs on SGI linux workstation / servers (330L and 1450). However if I try to stat a file larger than 2 GB, which is eventually done by a networker backup, I get an error: Value too large for defined data type Do we need an update of glibc or an "xfs aware" version of stat ? We are using XFS 1.0.1 on Linux sumba 2.4.3-SGI_XFS_1.0.1smp #1 SMP Mon Jul 9 14:03:40 CDT 2001 i686 unknown Any help would be appreciated. Thanks. Best regards Oliver Karch -- __________________________________________________________ Dr. Oliver Karch Frankfurter Str. 250 MERCK KGaA 64271 Darmstadt, Germany Medicinal Chemistry +49 6151 723825 (phone) Research Department +49 6151 723329 (fax) Bio- and Chemoinformatics http://www.merck.de From owner-linux-xfs@oss.sgi.com Mon Sep 3 07:32:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83EWcs18212 for linux-xfs-outgoing; Mon, 3 Sep 2001 07:32:38 -0700 Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83EWYd18170 for ; Mon, 3 Sep 2001 07:32:34 -0700 Received: from heppcl.ph.qmw.ac.uk ([138.37.50.187]) by zeta.qmw.ac.uk with esmtp (Exim 3.16 #1) id 15dum9-0005iF-00 for linux-xfs@oss.sgi.com; Mon, 03 Sep 2001 15:32:33 +0100 Received: from heppct.ph.qmw.ac.uk (heppct.ph.qmw.ac.uk [138.37.50.246]) by heppcl.ph.qmw.ac.uk (8.9.3/8.9.3) with ESMTP id PAA29892 for ; Mon, 3 Sep 2001 15:32:33 +0100 Received: from localhost (pd@localhost) by heppct.ph.qmw.ac.uk (8.11.2/8.9.3) with ESMTP id f83EWXR22748 for ; Mon, 3 Sep 2001 15:32:33 +0100 X-Authentication-Warning: heppct.ph.qmw.ac.uk: pd owned process doing -bs Date: Mon, 3 Sep 2001 15:32:33 +0100 (BST) From: "P.Dixon" To: Subject: about to try RAID.... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, We're about to try xfs and software raid. We've done this in the past using 3x Promise Ultra ATA 100TX2 controllers. However, I've seen on this list a few bad comments about Promise, so I was wondering if there are any alternatives that people think would be a better option. This is what we plan to do: Using a standard motherboad/CPU in a large tower case, we want to use 8x IBM 61.5 GB hard disks in a software RAID 5 configuration (using XFS of course). Any hints/tips would be greatly appreciated. Cheerio, Paul ------------------------------------------------------------------------------- Paul Dixon Email: P.Dixon@qmw.ac.uk Department of Physics Phone: (020) 7882 5054 Queen Mary, University of London Fax : (020) 7882 5054 Mile End Road, London E1 4NS URL : http://hepwww.ph.qmw.ac.uk/~pd ------------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Sep 3 07:36:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83Ea5e19656 for linux-xfs-outgoing; Mon, 3 Sep 2001 07:36:05 -0700 Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83Ea3d19624 for ; Mon, 3 Sep 2001 07:36:03 -0700 Received: from heppcl.ph.qmw.ac.uk ([138.37.50.187]) by zeta.qmw.ac.uk with esmtp (Exim 3.16 #1) id 15dupW-0005km-00 for linux-xfs@oss.sgi.com; Mon, 03 Sep 2001 15:36:02 +0100 Received: from heppct.ph.qmw.ac.uk (heppct.ph.qmw.ac.uk [138.37.50.246]) by heppcl.ph.qmw.ac.uk (8.9.3/8.9.3) with ESMTP id PAA29922 for ; Mon, 3 Sep 2001 15:36:02 +0100 Received: from localhost (pd@localhost) by heppct.ph.qmw.ac.uk (8.11.2/8.9.3) with ESMTP id f83Ea2L22775 for ; Mon, 3 Sep 2001 15:36:02 +0100 X-Authentication-Warning: heppct.ph.qmw.ac.uk: pd owned process doing -bs Date: Mon, 3 Sep 2001 15:36:02 +0100 (BST) From: "P.Dixon" To: Subject: Re: about to try RAID.... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > We're about to try xfs and software raid. We've done this in the past > using ext2 I should add! Paul From owner-linux-xfs@oss.sgi.com Mon Sep 3 07:53:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83ErGN26428 for linux-xfs-outgoing; Mon, 3 Sep 2001 07:53:16 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83ErAd26350 for ; Mon, 3 Sep 2001 07:53:10 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id QAA04130; Mon, 3 Sep 2001 16:53:07 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id QAA05495; Mon, 3 Sep 2001 16:53:07 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 1032457306; Mon, 3 Sep 2001 16:52:16 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id F18A125835; Mon, 3 Sep 2001 16:52:11 +0200 (CEST) Message-ID: <3B93991B.24B2798F@ch.sauter-bc.com> Date: Mon, 03 Sep 2001 16:52:11 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: "P.Dixon" Cc: linux-xfs@oss.sgi.com Subject: Re: about to try RAID.... References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "P.Dixon" schrieb: > > Hi, > > We're about to try xfs and software raid. We've done this in the past > using 3x Promise Ultra ATA 100TX2 controllers. However, I've seen on this > list a few bad comments about Promise, so I was wondering if there are any > alternatives that people think would be a better option. > > This is what we plan to do: > > Using a standard motherboad/CPU in a large tower case, we want to use 8x > IBM 61.5 GB hard disks in a software RAID 5 configuration (using XFS of > course). > > Any hints/tips would be greatly appreciated. I was trying something similar but without success due to the following reasons: 1) The 8 IBM drives IC35L060AVER07-0 (made in thailand, march 2001) where in fact unusable for what I planned to do. Six of them started to produce 'bad sectors' whithin two days of operation. Using the IBM Drive Fittness Test tool 'repaired' the disk but new errors came after some more hours of activity. It was even so bad that the RAID5 never synced because it always reached a bad sector while syncing. I will send all of the disks back to IBM but I'm not sure for what - to receive another 8 failing disks? 2) The Promise Ultra ATA 100TX2 has produced corrupt data in two Computers from DELL. One was Precision 220, the other PowerEdge 1400SC. This error occured only when accessing more than one disk simultaneously - be it on the onboard IDE controller or the Promise. It looks like we have a general problem here because the same was reported from VIA based motherboards. However, I'm using the Ultra ATA 100TX2 in my home server with four Quantum Fireball 15G on a AMD-K6-2 and it work absolutely stable! My advice is that you just check whether the Promise is stable in your system and you make sure the 8 drives are okay. Performance of the Promise controllers is very good. Simon > > Cheerio, > Paul > > ------------------------------------------------------------------------------- > Paul Dixon Email: P.Dixon@qmw.ac.uk > Department of Physics Phone: (020) 7882 5054 > Queen Mary, University of London Fax : (020) 7882 5054 > Mile End Road, London E1 4NS URL : http://hepwww.ph.qmw.ac.uk/~pd > ------------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Sep 3 09:16:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83GGFm30599 for linux-xfs-outgoing; Mon, 3 Sep 2001 09:16:15 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83GG7d30579 for ; Mon, 3 Sep 2001 09:16:07 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 5FE856703E for ; Mon, 3 Sep 2001 18:16:00 +0200 (CEST) Cc: linux-xfs@oss.sgi.com Subject: Re: about to try RAID.... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 3 Sep 2001 18:15:59 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 03.09.2001 18:16:08, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 03.09.2001 18:16:08, Serialize complete at 03.09.2001 18:16:08, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 03.09.2001 18:16:09, S/MIME Sign complete at 03.09.2001 18:16:09, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 03.09.2001 18:16:01, Serialize complete at 03.09.2001 18:16:01 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z12334_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z12334_boundary_sign Content-Type: text/plain; charset="us-ascii" On 03.09.2001 16:32:33 "P.Dixon" wrote: >Hi, > >We're about to try xfs and software raid. We've done this in the past >using 3x Promise Ultra ATA 100TX2 controllers. However, I've seen on >this >list a few bad comments about Promise, so I was wondering if there are >any >alternatives that people think would be a better option. > >This is what we plan to do: > >Using a standard motherboad/CPU in a large tower case, we want to use 8x >IBM 61.5 GB hard disks in a software RAID 5 configuration (using XFS of >course). > >Any hints/tips would be greatly appreciated. > >Cheerio, > Paul We use the 3ware IDE-Raidcontrollers for real Raid, so we don't have to care about the software-raid layer.......(And they are fast) cu michael ---------z12334_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM1MIICHaADAgECAgQ68WMUMA0GCSqGSIb3DQEBBAUAMIGeMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYDVQQLExdDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNz IDIgQ0EwHhcNMDEwNTAzMDAwMDAwWhcNMDIwNTAzMjM1OTAwWjCBnTELMAkGA1UE BhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgG A1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEaMBgGA1UEAxMR TWljaGFlbCBXYWhsYnJpbmsxIjAgBgkqhkiG9w0BCQEWE21pd0Bwcm9wYWNrLWRh dGEuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALIOckqT1A9Rhsfgt4Y0 A98B9yUW0jztpCFpnti1cj5hkjaB7bTj029ki6cVXwlmv/MzqrIB0AfqOhILTDOo OilUqAjydR5D88jKnLPT1JyIKOaMjjFWa26vmSB2lTp4RdPmbtkiQoUZ9cBvglMV FYL/b9gC6mEpLAAyAfV8pIrNAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAEZhuNN2 nawO0zgdlUS379E2LP1Y1UkqRvbs+JJt4o/9iICT9QtC1Xqfb2S1AUldHSrT83PW TUoNjpL+n/SYeDrq6UPkfCMrbO4XhwRcOy5b+xJG+5GfshrL0ENzBVF2SsSYWcoz cp6y0GAVI74Wf7W91QCPz4cyhr3AP7ASal15XjlXLyoNL+59AqD2elGWsU6OUCg8 qw2xG/2IYAcpMGgHpmab9OBtF4R8+2b9qnFDqWUPK+L6KjJpwPFvkYpgW4ESsW5L jQgfog9+/gB8GxFU1FXvcbnuaJFwudaq9wMyKiLWJIK0jVH5fUIUzEPOemOz8fhn zUNVTnhZVI/sF6wwggO6MIICoqADAgECAgQ5Td9zMA0GCSqGSIb3DQEBBAUAMIGe MQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYD VQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYD VQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBE YXRhIENsYXNzIDIgQ0EwHhcNMDAwNjE4MDAwMDAwWhcNMDIwNjE4MjM1OTAwWjCB njELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAG A1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEgR21iSDEgMB4G A1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sg RGF0YSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 4sC9VaqHbKulz8+2vUwsODP7NAtBFxlehMYd6zHoYgD67GKnTlQj0EKK+TtHfZvI VtPKBXo4xuwePOx34pS+yeg4Wu2Yt984UFvy5WGhaSOox5OTfQ040go0QP+GPcz/ 02q8sy/UKdEFH1Q7l4AMQoewr6mi12mSii2HudcA4oWBqshHrZG64TFbZ539M4Au DxFqxGISuozATaMw4UVzR4Jju7KUH+chhj7eTYxGr1a8Ov8xapOuSxwrR0Nm9qKl h1/b9tspuLC3wNP2SExBccmOOX1QPHI9uVOegkQX0kSFmL0kONzUIa9d9TAYyP5H /OazPHpKcb7evqyJh5gmNwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBMrCrpoVIi mshBQdBdtPVCBex75s8sb/qmPFwxTn8IHASc3AWtfBPmoEf1c5FcVUERLQFr6uQV RU5ejmJewyzzf+iKlGLjWPvWLghEibWm+GTm1rLJpe+YwgR6/5y874RhaUj3KFi7 yCJsUaF2qKgEv39Lq4VgdRihhB++ZF3zgj/dv7dwOwC2jgk8mAZf1Cp3jG8yhLnI ZIRbYOuZdUCpBzCRj1qfD+P4izFarG4sHo3k7kfkCzpsyDrCJojmXzzoF3diAm5Q PHWlYYhNA0i09m8hW9YpxhfBp7qmIIYd5tCOqjZVgiyA9RLb68a2PnS30LzIIsQH OtubyM8KT7WqAAAxgDCCAfgCAQEwgacwgZ4xCzAJBgNVBAYTAmRlMRswGQYDVQQI ExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgGA1UE ChMRUHJvcGFjayBEYXRhIEdtYkgxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSAwHgYDVQQDExdQcm9wYWNrIERhdGEgQ2xhc3MgMiBDQQIEOvFjFDAJ BgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDkwMzE2MTYwOVowIwYJKoZIhvcNAQkEMRYEFDq0eHeI3p47UoaJ c/cJLx5WvzvRMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZIhvcNAwIC AgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGAEsrYwPa3S9ppCwg1mmT5eN6naMiHS01+jW1R9TcancdsokfRTa9D WeaOakGvJywPIxr19JUJTMmu75SiFSUb1l7IUnyydeXL3rH7jN7MZZuo1aWnMvRz tN6sRkVs5/nwZqTTdYf0EGBjFnuuLRh1vxw6q+rA37wbv22qWq84wToAAAAAAAAA AA== ---------z12334_boundary_sign-- From owner-linux-xfs@oss.sgi.com Mon Sep 3 09:23:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83GN8v30836 for linux-xfs-outgoing; Mon, 3 Sep 2001 09:23:08 -0700 Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83GN6d30817 for ; Mon, 3 Sep 2001 09:23:06 -0700 Received: from heppcl.ph.qmw.ac.uk ([138.37.50.187]) by zeta.qmw.ac.uk with esmtp (Exim 3.16 #1) id 15dwV5-00076o-00 for linux-xfs@oss.sgi.com; Mon, 03 Sep 2001 17:23:03 +0100 Received: from heppct.ph.qmw.ac.uk (heppct.ph.qmw.ac.uk [138.37.50.246]) by heppcl.ph.qmw.ac.uk (8.9.3/8.9.3) with ESMTP id RAA31455 for ; Mon, 3 Sep 2001 17:23:04 +0100 Received: from localhost (pd@localhost) by heppct.ph.qmw.ac.uk (8.11.2/8.9.3) with ESMTP id f83GN4V23447 for ; Mon, 3 Sep 2001 17:23:04 +0100 X-Authentication-Warning: heppct.ph.qmw.ac.uk: pd owned process doing -bs Date: Mon, 3 Sep 2001 17:23:04 +0100 (BST) From: "P.Dixon" To: Subject: Re: about to try RAID.... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > We use the 3ware IDE-Raidcontrollers for real Raid, so we don't have to > care about the software-raid layer.......(And they are fast) > Lots of good comments about 3ware stuff - but can't actually find anyone selling these things in Britain! Cheerio, Paul From owner-linux-xfs@oss.sgi.com Mon Sep 3 09:54:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83Gs5P31271 for linux-xfs-outgoing; Mon, 3 Sep 2001 09:54:05 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83Gs1d31252 for ; Mon, 3 Sep 2001 09:54:01 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id PAA02483; Mon, 3 Sep 2001 15:59:26 +0200 (CEST) Message-Id: <4.3.2.7.2.20010903155822.03f95a40@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Sep 2001 15:58:43 +0200 To: Oliver.Karch@merck.de, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Value too large for defined data type Cc: BCIHelp@admin.bci.merck.de.sgi.com In-Reply-To: <3B93714A.55B0A38D@mailserver.bci.merck.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 14:02 3-9-2001 +0200, Oliver.Karch@merck.de wrote: >Hi, > >we are successfully using xfs on SGI linux workstation / servers (330L >and 1450). However if I try to stat a file larger than 2 GB, which is >eventually done by a networker backup, I get an error: > >Value too large for defined data type > >Do we need an update of glibc or an "xfs aware" version of stat ? We are >using XFS 1.0.1 on It's in the FAQ. Cheers >Linux sumba 2.4.3-SGI_XFS_1.0.1smp #1 SMP Mon Jul 9 14:03:40 CDT 2001 >i686 unknown > >Any help would be appreciated. Thanks. > >Best regards > >Oliver Karch > >-- >__________________________________________________________ >Dr. Oliver Karch Frankfurter Str. 250 >MERCK KGaA 64271 Darmstadt, Germany >Medicinal Chemistry +49 6151 723825 (phone) >Research Department +49 6151 723329 (fax) >Bio- and Chemoinformatics http://www.merck.de -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Sep 3 09:55:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83GtYW31402 for linux-xfs-outgoing; Mon, 3 Sep 2001 09:55:34 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83GtRd31383 for ; Mon, 3 Sep 2001 09:55:27 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 3716B6703E; Mon, 3 Sep 2001 18:55:21 +0200 (CEST) To: "P.Dixon" Cc: linux-xfs@oss.sgi.com Subject: Re: about to try RAID.... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 3 Sep 2001 18:55:20 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 03.09.2001 18:55:29, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 03.09.2001 18:55:29, Serialize complete at 03.09.2001 18:55:29, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 03.09.2001 18:55:29, S/MIME Sign complete at 03.09.2001 18:55:29, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 03.09.2001 18:55:21, Serialize complete at 03.09.2001 18:55:21 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z1706_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z1706_boundary_sign Content-Type: text/plain; charset="us-ascii" On 03.09.2001 18:23:04 "P.Dixon" wrote: >> We use the 3ware IDE-Raidcontrollers for real Raid, so we don't have >to >> care about the software-raid layer.......(And they are fast) >> >Lots of good comments about 3ware stuff - but can't actually find anyone >selling these things in Britain! > >Cheerio, > Paul Hi Paul, >From the 3ware homepage (www.3ware.com): United Kingdom: Distributor TMC Technology Ltd Caxton Place, Caxton Way, Stevenage, Hertfordshire. SG1 2UQ United Kingdom Tel. +44 1438 842 300 Fax. +44 1438 842 333 www.tmc-uk.com Contact: James Low email:sales@tmc-uk.com Tel. +44 1438 842 300 x317 ask them for resellers or direct buy ;-) cu micha ---------z1706_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM1MIICHaADAgECAgQ68WMUMA0GCSqGSIb3DQEBBAUAMIGeMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYDVQQLExdDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNz IDIgQ0EwHhcNMDEwNTAzMDAwMDAwWhcNMDIwNTAzMjM1OTAwWjCBnTELMAkGA1UE BhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgG A1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEaMBgGA1UEAxMR TWljaGFlbCBXYWhsYnJpbmsxIjAgBgkqhkiG9w0BCQEWE21pd0Bwcm9wYWNrLWRh dGEuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALIOckqT1A9Rhsfgt4Y0 A98B9yUW0jztpCFpnti1cj5hkjaB7bTj029ki6cVXwlmv/MzqrIB0AfqOhILTDOo OilUqAjydR5D88jKnLPT1JyIKOaMjjFWa26vmSB2lTp4RdPmbtkiQoUZ9cBvglMV FYL/b9gC6mEpLAAyAfV8pIrNAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAEZhuNN2 nawO0zgdlUS379E2LP1Y1UkqRvbs+JJt4o/9iICT9QtC1Xqfb2S1AUldHSrT83PW TUoNjpL+n/SYeDrq6UPkfCMrbO4XhwRcOy5b+xJG+5GfshrL0ENzBVF2SsSYWcoz cp6y0GAVI74Wf7W91QCPz4cyhr3AP7ASal15XjlXLyoNL+59AqD2elGWsU6OUCg8 qw2xG/2IYAcpMGgHpmab9OBtF4R8+2b9qnFDqWUPK+L6KjJpwPFvkYpgW4ESsW5L jQgfog9+/gB8GxFU1FXvcbnuaJFwudaq9wMyKiLWJIK0jVH5fUIUzEPOemOz8fhn zUNVTnhZVI/sF6wwggO6MIICoqADAgECAgQ5Td9zMA0GCSqGSIb3DQEBBAUAMIGe MQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYD VQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYD VQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBE YXRhIENsYXNzIDIgQ0EwHhcNMDAwNjE4MDAwMDAwWhcNMDIwNjE4MjM1OTAwWjCB njELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAG A1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEgR21iSDEgMB4G A1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sg RGF0YSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 4sC9VaqHbKulz8+2vUwsODP7NAtBFxlehMYd6zHoYgD67GKnTlQj0EKK+TtHfZvI VtPKBXo4xuwePOx34pS+yeg4Wu2Yt984UFvy5WGhaSOox5OTfQ040go0QP+GPcz/ 02q8sy/UKdEFH1Q7l4AMQoewr6mi12mSii2HudcA4oWBqshHrZG64TFbZ539M4Au DxFqxGISuozATaMw4UVzR4Jju7KUH+chhj7eTYxGr1a8Ov8xapOuSxwrR0Nm9qKl h1/b9tspuLC3wNP2SExBccmOOX1QPHI9uVOegkQX0kSFmL0kONzUIa9d9TAYyP5H /OazPHpKcb7evqyJh5gmNwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBMrCrpoVIi mshBQdBdtPVCBex75s8sb/qmPFwxTn8IHASc3AWtfBPmoEf1c5FcVUERLQFr6uQV RU5ejmJewyzzf+iKlGLjWPvWLghEibWm+GTm1rLJpe+YwgR6/5y874RhaUj3KFi7 yCJsUaF2qKgEv39Lq4VgdRihhB++ZF3zgj/dv7dwOwC2jgk8mAZf1Cp3jG8yhLnI ZIRbYOuZdUCpBzCRj1qfD+P4izFarG4sHo3k7kfkCzpsyDrCJojmXzzoF3diAm5Q PHWlYYhNA0i09m8hW9YpxhfBp7qmIIYd5tCOqjZVgiyA9RLb68a2PnS30LzIIsQH OtubyM8KT7WqAAAxgDCCAfgCAQEwgacwgZ4xCzAJBgNVBAYTAmRlMRswGQYDVQQI ExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgGA1UE ChMRUHJvcGFjayBEYXRhIEdtYkgxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSAwHgYDVQQDExdQcm9wYWNrIERhdGEgQ2xhc3MgMiBDQQIEOvFjFDAJ BgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDkwMzE2NTUyOVowIwYJKoZIhvcNAQkEMRYEFEwvikmijBIdaYo2 ciPnBNMp3yo1MEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZIhvcNAwIC AgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGAEN2jkkMHFdIzUX83nfOoXiaC9SiKUI9vOqQZEIgVbZyK61my47Qx Ip8LL1hzeWcJMJcbSQ0q89mI2dcx66fdX20oW5lHU6aLFPH3kcMG7rf8OTWA9vP9 VEKmYj07EeoLv7NxCkBFYWLRd7/TCLLx9tWK8MPAqlPWb/RSWSPtScQAAAAAAAAA AA== ---------z1706_boundary_sign-- From owner-linux-xfs@oss.sgi.com Mon Sep 3 10:41:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83Hfu432013 for linux-xfs-outgoing; Mon, 3 Sep 2001 10:41:56 -0700 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83Hfqd31994 for ; Mon, 3 Sep 2001 10:41:52 -0700 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Sep 2001 12:41:23 -0500 Message-ID: <85063BBE668FD411944400D0B744267A888526@AUSMAIL> From: "Gonyou, Austin" To: "'Seth Mos'" , "Gonyou, Austin" , XFS mailing list Subject: RE: System lock while accessing files causes file corruption Date: Mon, 3 Sep 2001 12:41:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk That's all well and good..but what about the configuration files? They are text and are not redundant in the same way. I know it's been done to death..and I've read a lot of this stuff, but even after making thanges, etc, especially if I use logbufs > 2, I can make this happen at will. That's why I've got concerns. I know about the points Keith made, and very valid in this case especially, but my major concern is deploying a TB size db only to get taken down that my configs are messed up. (yes, I know that's what backups and CVS are for) but that's not acceptable when talking about my primary FS. I'm going to go through as many iterations of this as I can to see if I can narrow down exactly what and where, what hardware, etc. We're about to do a major deployment and I'm just trying to do due dilligence, beyond the FAQ and random mails. Thanks for listening, and this can certainly come off-list if you feel that's best. I really don't want to beat a dead horse anymore than I have to. Assurance of success in this respect is very important. We don't have a lot of storage to throw around. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Seth Mos [mailto:knuffie@xs4all.nl] > Sent: Sunday, September 02, 2001 7:18 PM > To: Gonyou, Austin; XFS mailing list > Subject: Re: System lock while accessing files causes file corruption > > > At 18:16 2-9-2001 -0500, Gonyou, Austin wrote: > >Why is this? If I open a file, text/otherwise and the power > actually fails, > >(i turn it off), once in a while I get a corrupt file. Why > is this? What > >would happen if I was writing to some Oracle filesystems and > this situation > >occurred? Please advise. > > See the http://oss.sgi.com/projects/xfs/faq.html#nulls > > A database would survive since most have their own buffering and > transaction scheme. > > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. > From owner-linux-xfs@oss.sgi.com Mon Sep 3 11:03:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83I3i332464 for linux-xfs-outgoing; Mon, 3 Sep 2001 11:03:44 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83I3fd32445 for ; Mon, 3 Sep 2001 11:03:41 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f83I3Z324911 for linux-xfs@oss.sgi.com; Mon, 3 Sep 2001 14:03:35 -0400 Date: Mon, 3 Sep 2001 14:03:35 -0400 From: Alan Eldridge To: SGI XFS Dev List Subject: in xfsdump CVS:STREAM_MAX?? Message-ID: <20010903140335.A24744@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Last couple of days... gcc -O1 -g -DDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -DDMEXTATTR -I/usr/include/xfs -I/usr/include/attr '-DVERSION="1.1.3"' -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -I/usr/include/xfs -I/usr/include/attr -c -o cldmgr.o cldmgr.c cldmgr.c:65: STREAM_MAX' undeclared here (not in a function) cldmgr.c:65: size of array cld' has non-integer type cldmgr.c: In function cldmgr_create': cldmgr.c:109: STREAM_MAX' undeclared (first use in this function) cldmgr.c:109: (Each undeclared identifier is reported only once cldmgr.c:109: for each function it appears in.) make[1]: *** [cldmgr.o] Error 1 make: *** [default] Error 2 error: Bad exit status from /home/alane/rpm/tmp/rpm-tmp.16124 (%build) xfs-adventure> take STREAM_MAX I see no STREAM_MAX here. xfs-adventure> explain [alane@wwweasel idutils]$ (cd usr; aid STREAM_MAX);(cd kernel; aid STREAM_MAX) _POSIX_STREAM_MAX /usr/include/bits/posix1_lim.h _SC_STREAM_MAX /usr/include/bits/confname.h [alane@wwweasel idutils]$ -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Mon Sep 3 11:21:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83IL5w32754 for linux-xfs-outgoing; Mon, 3 Sep 2001 11:21:05 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83IKxd32735 for ; Mon, 3 Sep 2001 11:20:59 -0700 Received: from ausmail.coremetrics.com ([209.184.141.185]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA04810 for ; Mon, 3 Sep 2001 11:20:59 -0700 (PDT) mail_from (austin@coremetrics.com) Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Sep 2001 13:18:54 -0500 Message-ID: <85063BBE668FD411944400D0B744267A888527@AUSMAIL> From: "Gonyou, Austin" To: "Gonyou, Austin" , "'Seth Mos'" , "'XFS mailing list'" Subject: RE: System lock while accessing files causes file corruption Date: Mon, 3 Sep 2001 13:18:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk One quick not on this, is there anything I can do kernel wise to prevent this without striking a crapload of overhead on the system? -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Gonyou, Austin > Sent: Monday, September 03, 2001 12:41 PM > To: 'Seth Mos'; Gonyou, Austin; XFS mailing list > Subject: RE: System lock while accessing files causes file corruption > > > That's all well and good..but what about the configuration > files? They are text and are not redundant in the same way. I > know it's been done to death..and I've read a lot of this > stuff, but even after making thanges, etc, especially if I > use logbufs > 2, I can make this happen at will. That's why > I've got concerns. I know about the points Keith made, and > very valid in this case especially, but my major concern is > deploying a TB size db only to get taken down that my configs > are messed up. (yes, I know that's what backups and CVS are > for) but that's not acceptable when talking about my primary > FS. I'm going to go through as many iterations of this as I > can to see if I can narrow down exactly what and where, what > hardware, etc. We're about to do a major deployment and I'm > just trying to do due dilligence, beyond the FAQ and random > mails. Thanks for listening, and this can certainly come > off-list if you feel that's best. I really don't want to beat > a dead horse anymore than I have to. Assurance of success in > this respect is very important. We don't have a lot of > storage to throw around. > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-796-9023 > email: austin@coremetrics.com > > > -----Original Message----- > > From: Seth Mos [mailto:knuffie@xs4all.nl] > > Sent: Sunday, September 02, 2001 7:18 PM > > To: Gonyou, Austin; XFS mailing list > > Subject: Re: System lock while accessing files causes file > corruption > > > > > > At 18:16 2-9-2001 -0500, Gonyou, Austin wrote: > > >Why is this? If I open a file, text/otherwise and the power > > actually fails, > > >(i turn it off), once in a while I get a corrupt file. Why > > is this? What > > >would happen if I was writing to some Oracle filesystems and > > this situation > > >occurred? Please advise. > > > > See the http://oss.sgi.com/projects/xfs/faq.html#nulls > > > > A database would survive since most have their own buffering and > > transaction scheme. > > > > > > -- > > Seth > > Every program has two purposes one for which > > it was written and another for which it wasn't > > I use the last kind. > > > From owner-linux-xfs@oss.sgi.com Mon Sep 3 13:50:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83Koe501847 for linux-xfs-outgoing; Mon, 3 Sep 2001 13:50:40 -0700 Received: from msg.ecetra.com (dollar.ecetra.com [193.164.224.209]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83KoWd01828 for ; Mon, 3 Sep 2001 13:50:32 -0700 Received: from vie-ac.office.ecetra.com (vie-ac.office.ecetra.com [10.251.148.147] (may be forged)) by msg.ecetra.com (8.9.3/8.9.3) with ESMTP id WAA07799; Mon, 3 Sep 2001 22:50:25 +0200 Received: from localhost (localhost [127.0.0.1]) by vie-ac.office.ecetra.com (8.11.4/8.11.3) with ESMTP id f83KoOx31451; Mon, 3 Sep 2001 22:50:24 +0200 Date: Mon, 3 Sep 2001 22:50:24 +0200 (CEST) From: Adam Cioccarelli To: "Gonyou, Austin" cc: Subject: RE: System lock while accessing files causes file corruption In-Reply-To: <85063BBE668FD411944400D0B744267A888527@AUSMAIL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just one point... Oracle just has one configuration file, initxxx.ora and this only read by the database at startup, it never writes to this file. If you ever lose it you can easily recreate it by taking a look in the alert logs which show all non default parameters taken from the init file. Anyway I think that the point is that where you might end up with a file that is just garbage on an xfs filesystem, you wouldn't have any file at all on ext2, or at least that is my undersatnding... ------------------------------------------------------------------------------- Adam Cioccarelli (B.E Mechanical) Adam.Cioccarelli@ecetra.com Database Administrator Phone: +43 1 536 89 7725 Fax: +43 1 536 89 7719 ecetra Central European e-Finance AG Mobile:+43 664 181 4195 ------------------------------------------------------------------------------- On Mon, 3 Sep 2001, Gonyou, Austin wrote: > One quick not on this, is there anything I can do kernel wise to prevent > this without striking a crapload of overhead on the system? > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-796-9023 > email: austin@coremetrics.com > > > -----Original Message----- > > From: Gonyou, Austin > > Sent: Monday, September 03, 2001 12:41 PM > > To: 'Seth Mos'; Gonyou, Austin; XFS mailing list > > Subject: RE: System lock while accessing files causes file corruption > > > > > > That's all well and good..but what about the configuration > > files? They are text and are not redundant in the same way. I > > know it's been done to death..and I've read a lot of this > > stuff, but even after making thanges, etc, especially if I > > use logbufs > 2, I can make this happen at will. That's why > > I've got concerns. I know about the points Keith made, and > > very valid in this case especially, but my major concern is > > deploying a TB size db only to get taken down that my configs > > are messed up. (yes, I know that's what backups and CVS are > > for) but that's not acceptable when talking about my primary > > FS. I'm going to go through as many iterations of this as I > > can to see if I can narrow down exactly what and where, what > > hardware, etc. We're about to do a major deployment and I'm > > just trying to do due dilligence, beyond the FAQ and random > > mails. Thanks for listening, and this can certainly come > > off-list if you feel that's best. I really don't want to beat > > a dead horse anymore than I have to. Assurance of success in > > this respect is very important. We don't have a lot of > > storage to throw around. > > > > -- > > Austin Gonyou > > Systems Architect, CCNA > > Coremetrics, Inc. > > Phone: 512-796-9023 > > email: austin@coremetrics.com > > > > > -----Original Message----- > > > From: Seth Mos [mailto:knuffie@xs4all.nl] > > > Sent: Sunday, September 02, 2001 7:18 PM > > > To: Gonyou, Austin; XFS mailing list > > > Subject: Re: System lock while accessing files causes file > > corruption > > > > > > > > > At 18:16 2-9-2001 -0500, Gonyou, Austin wrote: > > > >Why is this? If I open a file, text/otherwise and the power > > > actually fails, > > > >(i turn it off), once in a while I get a corrupt file. Why > > > is this? What > > > >would happen if I was writing to some Oracle filesystems and > > > this situation > > > >occurred? Please advise. > > > > > > See the http://oss.sgi.com/projects/xfs/faq.html#nulls > > > > > > A database would survive since most have their own buffering and > > > transaction scheme. > > > > > > > > > -- > > > Seth > > > Every program has two purposes one for which > > > it was written and another for which it wasn't > > > I use the last kind. > > > > > > From owner-linux-xfs@oss.sgi.com Mon Sep 3 13:56:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83KuR902017 for linux-xfs-outgoing; Mon, 3 Sep 2001 13:56:27 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83KuLd01998 for ; Mon, 3 Sep 2001 13:56:21 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA17374; Mon, 3 Sep 2001 22:56:20 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA16805; Mon, 3 Sep 2001 22:56:19 +0200 (CEST) Date: Mon, 3 Sep 2001 22:56:19 +0200 (CEST) From: Seth Mos To: "Gonyou, Austin" cc: "'XFS mailing list'" Subject: RE: System lock while accessing files causes file corruption In-Reply-To: <85063BBE668FD411944400D0B744267A888527@AUSMAIL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 3 Sep 2001, Gonyou, Austin wrote: > One quick not on this, is there anything I can do kernel wise to prevent > this without striking a crapload of overhead on the system? No, all metadata journaling filesystems have this. ReiserFS has it and I suspect that JFS can do this as well. If I ever get the NCR MP-RAS box to be out of production I could test this with Veritas as well. I hate to say it but this a general metadata jfs problem/feature. It needs a smarter kernel to make it go to disk faster when the box is not loaded. > > -----Original Message----- > > From: Gonyou, Austin > > Sent: Monday, September 03, 2001 12:41 PM > > To: 'Seth Mos'; Gonyou, Austin; XFS mailing list > > Subject: RE: System lock while accessing files causes file corruption > > > > > > That's all well and good..but what about the configuration > > files? They are text and are not redundant in the same way. I > > know it's been done to death..and I've read a lot of this > > stuff, but even after making thanges, etc, especially if I > > use logbufs > 2, I can make this happen at will. That's why > > I've got concerns. I know about the points Keith made, and > > very valid in this case especially, but my major concern is > > deploying a TB size db only to get taken down that my configs > > are messed up. (yes, I know that's what backups and CVS are > > for) but that's not acceptable when talking about my primary > > FS. I'm going to go through as many iterations of this as I > > can to see if I can narrow down exactly what and where, what > > hardware, etc. We're about to do a major deployment and I'm > > just trying to do due dilligence, beyond the FAQ and random > > mails. Thanks for listening, and this can certainly come > > off-list if you feel that's best. I really don't want to beat > > a dead horse anymore than I have to. Assurance of success in > > this respect is very important. We don't have a lot of > > storage to throw around. > > > > -- > > Austin Gonyou > > Systems Architect, CCNA > > Coremetrics, Inc. > > Phone: 512-796-9023 > > email: austin@coremetrics.com > > > > > -----Original Message----- > > > From: Seth Mos [mailto:knuffie@xs4all.nl] > > > Sent: Sunday, September 02, 2001 7:18 PM > > > To: Gonyou, Austin; XFS mailing list > > > Subject: Re: System lock while accessing files causes file > > corruption > > > > > > > > > At 18:16 2-9-2001 -0500, Gonyou, Austin wrote: > > > >Why is this? If I open a file, text/otherwise and the power > > > actually fails, > > > >(i turn it off), once in a while I get a corrupt file. Why > > > is this? What > > > >would happen if I was writing to some Oracle filesystems and > > > this situation > > > >occurred? Please advise. > > > > > > See the http://oss.sgi.com/projects/xfs/faq.html#nulls > > > > > > A database would survive since most have their own buffering and > > > transaction scheme. > > > > > > > > > -- > > > Seth > > > Every program has two purposes one for which > > > it was written and another for which it wasn't > > > I use the last kind. > > > > > > > From owner-linux-xfs@oss.sgi.com Mon Sep 3 14:10:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83LAoA02444 for linux-xfs-outgoing; Mon, 3 Sep 2001 14:10:50 -0700 Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83LAmd02425 for ; Mon, 3 Sep 2001 14:10:48 -0700 Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 15e0zS-000NVP-0Y for linux-xfs@oss.sgi.com; Mon, 3 Sep 2001 22:10:44 +0100 Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3]) by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id 02FA027F0 for ; Mon, 3 Sep 2001 22:10:40 +0100 (BST) Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001) id 10E04125E6; Mon, 3 Sep 2001 22:10:40 +0100 (BST) Date: Mon, 3 Sep 2001 22:10:39 +0100 (BST) From: Keith Matthews Subject: Re[2]: System lock while accessing files causes file corruption To: linux-xfs@oss.sgi.com In-Reply-To: References: X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Disposition: INLINE Message-Id: <20010903211040.10E04125E6@rebutia.sweeney.demon.co.uk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f83LAmd02426 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 3 Sep 2001 22:50:24 +0200 (CEST) Adam Cioccarelli > wrote: > > Just one point... Oracle just has one configuration file, initxxx.ora and > this only read by the database at startup, it never writes to this file. > If you ever lose it you can easily recreate it by taking a look in the > alert logs which show all non default parameters taken from the init file From owner-linux-xfs@oss.sgi.com Mon Sep 3 14:18:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83LIjq02643 for linux-xfs-outgoing; Mon, 3 Sep 2001 14:18:45 -0700 Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83LIed02617 for ; Mon, 3 Sep 2001 14:18:40 -0700 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.2/8.11.2) with ESMTP id f83LIqT18811; Mon, 3 Sep 2001 23:18:52 +0200 Date: Mon, 3 Sep 2001 23:18:52 +0200 (CEST) From: Matteo Centonza To: "P.Dixon" cc: Subject: Re: about to try RAID.... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, we actually use a Promise Ultra ATA 100 and an on board controller with 4 IBM DTLA hd with LVM on top of soft RAID5 (Athlon 1.33 Ghz). This setup is in production, updating the kernel cvs every once in a while, since early june, it's rock solid, and recently saved our ass when our server keep on crashing hergodically (10 times per day due to a power supply defect, avoiding the consequent 140 Gb fs check). Thanks to XFS(primarily) and LVM, we have extremely valid HA solution for linux. Thanks a lot guys. Ciao, -m On Mon, 3 Sep 2001, P.Dixon wrote: > Hi, > > We're about to try xfs and software raid. We've done this in the past > using 3x Promise Ultra ATA 100TX2 controllers. However, I've seen on this > list a few bad comments about Promise, so I was wondering if there are any > alternatives that people think would be a better option. > > This is what we plan to do: > > Using a standard motherboad/CPU in a large tower case, we want to use 8x > IBM 61.5 GB hard disks in a software RAID 5 configuration (using XFS of > course). > > Any hints/tips would be greatly appreciated. > > Cheerio, > Paul > > ------------------------------------------------------------------------------- > Paul Dixon Email: P.Dixon@qmw.ac.uk > Department of Physics Phone: (020) 7882 5054 > Queen Mary, University of London Fax : (020) 7882 5054 > Mile End Road, London E1 4NS URL : http://hepwww.ph.qmw.ac.uk/~pd > ------------------------------------------------------------------------------- > From owner-linux-xfs@oss.sgi.com Mon Sep 3 14:23:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83LNNb02788 for linux-xfs-outgoing; Mon, 3 Sep 2001 14:23:23 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83LN2d02768; Mon, 3 Sep 2001 14:23:02 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id EF44D6703F; Mon, 3 Sep 2001 23:22:55 +0200 (CEST) To: "Michael Wahlbrink" Cc: Keith Owens , Seth Mos , linux-xfs@oss.sgi.com, Michael Wahlbrink , owner-linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 3 Sep 2001 23:22:54 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 03.09.2001 23:23:04, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 03.09.2001 23:23:04, Serialize complete at 03.09.2001 23:23:04, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 03.09.2001 23:23:04, S/MIME Sign complete at 03.09.2001 23:23:04, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 03.09.2001 23:22:56, Serialize complete at 03.09.2001 23:22:56 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z18235_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z18235_boundary_sign Content-Type: text/plain; charset="us-ascii" On 02.09.2001 00:07:42 "Michael Wahlbrink" wrote: >Ok, no problem ;-) > >I'll make my tests with ext2 to see if the kernel 'oopses' too......... >And the PII is still compiling th xfs kernel.... > >cu >michael > Ok, I think I've found the error! :-)) I've made the tests also with ext2 and run into IO errors...... I checked the drives and burned my fingers...... The drives are getting to hot :-( So I installed a additional cooler and all was nearly fine... Because of all the compilation tries and tests my system was unusuable and i get more and more strange errors (also from xfs)...... So i installed a new clean system (2.4.10-pre4-xfs), and now its working.......! On the PII its also working fine..... But there is one thing, why does ext2 says that it have IO Problems when writing to disk and xfs simply dies with an oops when you try to acess the corrupt data ???? cu michael ---------z18235_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM1MIICHaADAgECAgQ68WMUMA0GCSqGSIb3DQEBBAUAMIGeMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYDVQQLExdDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNz IDIgQ0EwHhcNMDEwNTAzMDAwMDAwWhcNMDIwNTAzMjM1OTAwWjCBnTELMAkGA1UE BhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgG A1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEaMBgGA1UEAxMR TWljaGFlbCBXYWhsYnJpbmsxIjAgBgkqhkiG9w0BCQEWE21pd0Bwcm9wYWNrLWRh dGEuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALIOckqT1A9Rhsfgt4Y0 A98B9yUW0jztpCFpnti1cj5hkjaB7bTj029ki6cVXwlmv/MzqrIB0AfqOhILTDOo OilUqAjydR5D88jKnLPT1JyIKOaMjjFWa26vmSB2lTp4RdPmbtkiQoUZ9cBvglMV FYL/b9gC6mEpLAAyAfV8pIrNAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAEZhuNN2 nawO0zgdlUS379E2LP1Y1UkqRvbs+JJt4o/9iICT9QtC1Xqfb2S1AUldHSrT83PW TUoNjpL+n/SYeDrq6UPkfCMrbO4XhwRcOy5b+xJG+5GfshrL0ENzBVF2SsSYWcoz cp6y0GAVI74Wf7W91QCPz4cyhr3AP7ASal15XjlXLyoNL+59AqD2elGWsU6OUCg8 qw2xG/2IYAcpMGgHpmab9OBtF4R8+2b9qnFDqWUPK+L6KjJpwPFvkYpgW4ESsW5L jQgfog9+/gB8GxFU1FXvcbnuaJFwudaq9wMyKiLWJIK0jVH5fUIUzEPOemOz8fhn zUNVTnhZVI/sF6wwggO6MIICoqADAgECAgQ5Td9zMA0GCSqGSIb3DQEBBAUAMIGe MQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYD VQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYD VQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBE YXRhIENsYXNzIDIgQ0EwHhcNMDAwNjE4MDAwMDAwWhcNMDIwNjE4MjM1OTAwWjCB njELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAG A1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEgR21iSDEgMB4G A1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sg RGF0YSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 4sC9VaqHbKulz8+2vUwsODP7NAtBFxlehMYd6zHoYgD67GKnTlQj0EKK+TtHfZvI VtPKBXo4xuwePOx34pS+yeg4Wu2Yt984UFvy5WGhaSOox5OTfQ040go0QP+GPcz/ 02q8sy/UKdEFH1Q7l4AMQoewr6mi12mSii2HudcA4oWBqshHrZG64TFbZ539M4Au DxFqxGISuozATaMw4UVzR4Jju7KUH+chhj7eTYxGr1a8Ov8xapOuSxwrR0Nm9qKl h1/b9tspuLC3wNP2SExBccmOOX1QPHI9uVOegkQX0kSFmL0kONzUIa9d9TAYyP5H /OazPHpKcb7evqyJh5gmNwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBMrCrpoVIi mshBQdBdtPVCBex75s8sb/qmPFwxTn8IHASc3AWtfBPmoEf1c5FcVUERLQFr6uQV RU5ejmJewyzzf+iKlGLjWPvWLghEibWm+GTm1rLJpe+YwgR6/5y874RhaUj3KFi7 yCJsUaF2qKgEv39Lq4VgdRihhB++ZF3zgj/dv7dwOwC2jgk8mAZf1Cp3jG8yhLnI ZIRbYOuZdUCpBzCRj1qfD+P4izFarG4sHo3k7kfkCzpsyDrCJojmXzzoF3diAm5Q PHWlYYhNA0i09m8hW9YpxhfBp7qmIIYd5tCOqjZVgiyA9RLb68a2PnS30LzIIsQH OtubyM8KT7WqAAAxgDCCAfgCAQEwgacwgZ4xCzAJBgNVBAYTAmRlMRswGQYDVQQI ExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgGA1UE ChMRUHJvcGFjayBEYXRhIEdtYkgxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSAwHgYDVQQDExdQcm9wYWNrIERhdGEgQ2xhc3MgMiBDQQIEOvFjFDAJ BgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDkwMzIxMjMwNFowIwYJKoZIhvcNAQkEMRYEFPV8P2EO6q2OrzhK Hx+Co7FjxjmLMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZIhvcNAwIC AgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGAALTQDaK8fkNJKSCcFDDhRFOmU1qMQ2pYgqbXhVXF0BbnjMknk+Jz dbKSf6uChjIJZKtmlvolrOqAzEKqi7jq4AVf2q/im13WEEfEAMCUUoC39ne/0Ysl GpTvdadchaOT0I1qYzArkOHOWb4YHBjOFeE15fEgIy6RwnT7xliINW4AAAAAAAAA AA== ---------z18235_boundary_sign-- From owner-linux-xfs@oss.sgi.com Mon Sep 3 14:33:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83LX4V03124 for linux-xfs-outgoing; Mon, 3 Sep 2001 14:33:04 -0700 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83LWvd03104 for ; Mon, 3 Sep 2001 14:32:57 -0700 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Sep 2001 16:32:25 -0500 Message-ID: <85063BBE668FD411944400D0B744267A88852A@AUSMAIL> From: "Gonyou, Austin" To: "'XFS mailing list'" Subject: RE: System lock while accessing files causes file corruption Date: Mon, 3 Sep 2001 16:32:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk All, Thanks so much for your input on this and not flaming the living daylights out of me. The info I've gathered here from everyone's feedback is sure enough to be good armament should I run into problems helping people understand things. Knowing the reality of things vs. "facts" is very important. Thank you all again for your help. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Seth Mos [mailto:knuffie@xs4all.nl] > Sent: Monday, September 03, 2001 3:56 PM > To: Gonyou, Austin > Cc: 'XFS mailing list' > Subject: RE: System lock while accessing files causes file corruption > > > On Mon, 3 Sep 2001, Gonyou, Austin wrote: > > > One quick not on this, is there anything I can do kernel > wise to prevent > > this without striking a crapload of overhead on the system? > > No, all metadata journaling filesystems have this. ReiserFS > has it and I > suspect that JFS can do this as well. If I ever get the NCR > MP-RAS box to > be out of production I could test this with Veritas as well. > > I hate to say it but this a general metadata jfs > problem/feature. It needs > a smarter kernel to make it go to disk faster when the box is > not loaded. > > > > -----Original Message----- > > > From: Gonyou, Austin > > > Sent: Monday, September 03, 2001 12:41 PM > > > To: 'Seth Mos'; Gonyou, Austin; XFS mailing list > > > Subject: RE: System lock while accessing files causes > file corruption > > > > > > > > > That's all well and good..but what about the configuration > > > files? They are text and are not redundant in the same way. I > > > know it's been done to death..and I've read a lot of this > > > stuff, but even after making thanges, etc, especially if I > > > use logbufs > 2, I can make this happen at will. That's why > > > I've got concerns. I know about the points Keith made, and > > > very valid in this case especially, but my major concern is > > > deploying a TB size db only to get taken down that my configs > > > are messed up. (yes, I know that's what backups and CVS are > > > for) but that's not acceptable when talking about my primary > > > FS. I'm going to go through as many iterations of this as I > > > can to see if I can narrow down exactly what and where, what > > > hardware, etc. We're about to do a major deployment and I'm > > > just trying to do due dilligence, beyond the FAQ and random > > > mails. Thanks for listening, and this can certainly come > > > off-list if you feel that's best. I really don't want to beat > > > a dead horse anymore than I have to. Assurance of success in > > > this respect is very important. We don't have a lot of > > > storage to throw around. > > > > > > -- > > > Austin Gonyou > > > Systems Architect, CCNA > > > Coremetrics, Inc. > > > Phone: 512-796-9023 > > > email: austin@coremetrics.com > > > > > > > -----Original Message----- > > > > From: Seth Mos [mailto:knuffie@xs4all.nl] > > > > Sent: Sunday, September 02, 2001 7:18 PM > > > > To: Gonyou, Austin; XFS mailing list > > > > Subject: Re: System lock while accessing files causes file > > > corruption > > > > > > > > > > > > At 18:16 2-9-2001 -0500, Gonyou, Austin wrote: > > > > >Why is this? If I open a file, text/otherwise and the power > > > > actually fails, > > > > >(i turn it off), once in a while I get a corrupt file. Why > > > > is this? What > > > > >would happen if I was writing to some Oracle filesystems and > > > > this situation > > > > >occurred? Please advise. > > > > > > > > See the http://oss.sgi.com/projects/xfs/faq.html#nulls > > > > > > > > A database would survive since most have their own > buffering and > > > > transaction scheme. > > > > > > > > > > > > -- > > > > Seth > > > > Every program has two purposes one for which > > > > it was written and another for which it wasn't > > > > I use the last kind. > > > > > > > > > > > > From owner-linux-xfs@oss.sgi.com Mon Sep 3 14:48:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83LmbL03452 for linux-xfs-outgoing; Mon, 3 Sep 2001 14:48:37 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83LmTd03433 for ; Mon, 3 Sep 2001 14:48:29 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA01658; Mon, 3 Sep 2001 23:48:27 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA27542; Mon, 3 Sep 2001 23:48:27 +0200 (CEST) Date: Mon, 3 Sep 2001 23:48:27 +0200 (CEST) From: Seth Mos To: "Gonyou, Austin" cc: "'XFS mailing list'" Subject: RE: System lock while accessing files causes file corruption In-Reply-To: <85063BBE668FD411944400D0B744267A88852A@AUSMAIL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 3 Sep 2001, Gonyou, Austin wrote: > All, > Thanks so much for your input on this and not flaming the living > daylights out of me. The info I've gathered here from everyone's feedback is You have to give me a good reason first. Since my new laptop arived I don't really care ;-) > sure enough to be good armament should I run into problems helping people > understand things. Knowing the reality of things vs. "facts" is very > important. Thank you all again for your help. You're welcome > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-796-9023 > email: austin@coremetrics.com > > > -----Original Message----- > > From: Seth Mos [mailto:knuffie@xs4all.nl] > > Sent: Monday, September 03, 2001 3:56 PM > > To: Gonyou, Austin > > Cc: 'XFS mailing list' > > Subject: RE: System lock while accessing files causes file corruption > > > > > > On Mon, 3 Sep 2001, Gonyou, Austin wrote: > > > > > One quick not on this, is there anything I can do kernel > > wise to prevent > > > this without striking a crapload of overhead on the system? > > > > No, all metadata journaling filesystems have this. ReiserFS > > has it and I > > suspect that JFS can do this as well. If I ever get the NCR > > MP-RAS box to > > be out of production I could test this with Veritas as well. > > > > I hate to say it but this a general metadata jfs > > problem/feature. It needs > > a smarter kernel to make it go to disk faster when the box is > > not loaded. > > > > > > -----Original Message----- > > > > From: Gonyou, Austin > > > > Sent: Monday, September 03, 2001 12:41 PM > > > > To: 'Seth Mos'; Gonyou, Austin; XFS mailing list > > > > Subject: RE: System lock while accessing files causes > > file corruption > > > > > > > > > > > > That's all well and good..but what about the configuration > > > > files? They are text and are not redundant in the same way. I > > > > know it's been done to death..and I've read a lot of this > > > > stuff, but even after making thanges, etc, especially if I > > > > use logbufs > 2, I can make this happen at will. That's why > > > > I've got concerns. I know about the points Keith made, and > > > > very valid in this case especially, but my major concern is > > > > deploying a TB size db only to get taken down that my configs > > > > are messed up. (yes, I know that's what backups and CVS are > > > > for) but that's not acceptable when talking about my primary > > > > FS. I'm going to go through as many iterations of this as I > > > > can to see if I can narrow down exactly what and where, what > > > > hardware, etc. We're about to do a major deployment and I'm > > > > just trying to do due dilligence, beyond the FAQ and random > > > > mails. Thanks for listening, and this can certainly come > > > > off-list if you feel that's best. I really don't want to beat > > > > a dead horse anymore than I have to. Assurance of success in > > > > this respect is very important. We don't have a lot of > > > > storage to throw around. > > > > > > > > -- > > > > Austin Gonyou > > > > Systems Architect, CCNA > > > > Coremetrics, Inc. > > > > Phone: 512-796-9023 > > > > email: austin@coremetrics.com > > > > > > > > > -----Original Message----- > > > > > From: Seth Mos [mailto:knuffie@xs4all.nl] > > > > > Sent: Sunday, September 02, 2001 7:18 PM > > > > > To: Gonyou, Austin; XFS mailing list > > > > > Subject: Re: System lock while accessing files causes file > > > > corruption > > > > > > > > > > > > > > > At 18:16 2-9-2001 -0500, Gonyou, Austin wrote: > > > > > >Why is this? If I open a file, text/otherwise and the power > > > > > actually fails, > > > > > >(i turn it off), once in a while I get a corrupt file. Why > > > > > is this? What > > > > > >would happen if I was writing to some Oracle filesystems and > > > > > this situation > > > > > >occurred? Please advise. > > > > > > > > > > See the http://oss.sgi.com/projects/xfs/faq.html#nulls > > > > > > > > > > A database would survive since most have their own > > buffering and > > > > > transaction scheme. > > > > > > > > > > > > > > > -- > > > > > Seth > > > > > Every program has two purposes one for which > > > > > it was written and another for which it wasn't > > > > > I use the last kind. > > > > > > > > > > > > > > > > > > > From owner-linux-xfs@oss.sgi.com Mon Sep 3 16:57:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f83NvnJ05162 for linux-xfs-outgoing; Mon, 3 Sep 2001 16:57:49 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f83Nvld05143 for ; Mon, 3 Sep 2001 16:57:47 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA02726 for ; Mon, 3 Sep 2001 16:57:34 -0700 (PDT) mail_from (ajag@snort.melbourne.sgi.com) Received: (from ajag@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA92509 for linux-xfs@oss.sgi.com; Tue, 4 Sep 2001 09:56:09 +1000 (EST) Date: Tue, 4 Sep 2001 09:56:09 +1000 (EST) From: Andrew Gildfind Message-Id: <200109032356.JAA92509@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Fix xfsdump build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Un-STREAM_MAXify... undo mod 2.4.x-xfs:slinx:101997a and fix the remaining STREAM_MAX's.. Date: Mon Sep 3 16:53:47 PDT 2001 Workarea: snort.melbourne.sgi.com:/home/ajag/isms/slinx Undoes mod: 2.4.x-xfs:slinx:101997a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102075a cmd/xfsdump/dump/content.c - 1.10 cmd/xfsdump/common/stream.c - 1.4 cmd/xfsdump/common/mlog.c - 1.3 cmd/xfsdump/common/main.c - 1.9 cmd/xfsdump/common/cldmgr.c - 1.4 cmd/xfsdump/restore/content.c - 1.14 From owner-linux-xfs@oss.sgi.com Mon Sep 3 17:24:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f840ONo05634 for linux-xfs-outgoing; Mon, 3 Sep 2001 17:24:23 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f840OKd05614 for ; Mon, 3 Sep 2001 17:24:20 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f840OE524643 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Mon, 3 Sep 2001 17:24:14 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id CAA860667 for ; Tue, 4 Sep 2001 02:24:13 +0200 (CEST) mail_from (ajag@snort.melbourne.sgi.com) Received: (from ajag@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA49510 for linux-xfs@oss.sgi.com; Tue, 4 Sep 2001 10:22:51 +1000 (EST) Date: Tue, 4 Sep 2001 10:22:51 +1000 (EST) From: Andrew Gildfind Message-Id: <200109040022.KAA49510@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Fix xfsdump build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sync with IRIX, remove warnings... Date: Mon Sep 3 17:21:28 PDT 2001 Workarea: snort.melbourne.sgi.com:/home/ajag/isms/slinx The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102078a cmd/xfsdump/common/mlog.c - 1.4 cmd/xfsdump/common/main.c - 1.10 - Remove warnings From owner-linux-xfs@oss.sgi.com Mon Sep 3 19:03:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8423a707148 for linux-xfs-outgoing; Mon, 3 Sep 2001 19:03:36 -0700 Received: from longsword.omniti.com (IDENT:exim@longsword.omniti.com [216.0.51.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8423Xd07129 for ; Mon, 3 Sep 2001 19:03:33 -0700 Received: from warhammer.omniti.com ([216.0.51.145] helo=omniti.com) by longsword.omniti.com with esmtp (Exim 3.22 #2) id 15e5Yo-0003fz-00; Mon, 03 Sep 2001 22:03:30 -0400 Message-ID: <3B943672.4040302@omniti.com> Date: Mon, 03 Sep 2001 22:03:30 -0400 From: "Theo E. Schlossnagle" Organization: OmniTI, Inc. -- Computer Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802 X-Accept-Language: en-us MIME-Version: 1.0 To: Paul Schutte CC: exim-users@exim.org, linux-xfs@oss.sgi.com Subject: Re: [Exim] Re: Exim and XFS filesystem References: <3B8BB7C7.4020808@omniti.com> <3B929216.B2D4AC60@it.up.ac.za> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Paul Schutte wrote: > What mount options did you use ? Mounting xfs for /var/spool with options: logbufs=8,logbsize=32768 Mounting xfs for /var with options: defaults. My install of exim writes everything but logs into /var/spool, logs it writes into /var. -- Theo Schlossnagle 1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984 2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7 From owner-linux-xfs@oss.sgi.com Mon Sep 3 20:54:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f843s3d09079 for linux-xfs-outgoing; Mon, 3 Sep 2001 20:54:03 -0700 Received: from webber.adilger.int (h24-64-71-161.cg.shawcable.net [24.64.71.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f843s0d09060 for ; Mon, 3 Sep 2001 20:54:00 -0700 Received: from webber.adilger.int (adilger@localhost [127.0.0.1]) by localhost (8.12.0.Beta10/8.12.0.Beta10/Debian 8.12.0.Beta10) with ESMTP id f843r14h032579; Mon, 3 Sep 2001 21:53:02 -0600 Received: (from adilger@localhost) by webber.adilger.int (8.12.0.Beta10/8.12.0.Beta10/Debian 8.12.0.Beta10) id f843r0wN032577; Mon, 3 Sep 2001 21:53:00 -0600 From: Andreas Dilger Date: Mon, 3 Sep 2001 21:53:00 -0600 To: linux-lvm@sistina.com Cc: linux-xfs@oss.sgi.com, akpm@zip.com.au, neilb@cse.unsw.edu.au Subject: Re: [linux-lvm] PBs with LVM over software RAID ( and XFS ? ext2 reiserfs?) Message-ID: <20010903215300.B32553@turbolinux.com> Mail-Followup-To: linux-lvm@sistina.com, linux-xfs@oss.sgi.com, akpm@zip.com.au, neilb@cse.unsw.edu.au References: <3B8E3F0E.8050609@st-peter.stw.uni-erlangen.de> <20010830083546.A20989@sistina.com> <3B8EC633.40202@st-peter.stw.uni-erlangen.de> <3B8F8C5E.7030603@st-peter.stw.uni-erlangen.de> <20010831110512.V541@turbolinux.com> <3B90C9A4.3080005@st-peter.stw.uni-erlangen.de> <3B90EC90.4050606@st-peter.stw.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B90EC90.4050606@st-peter.stw.uni-erlangen.de> User-Agent: Mutt/1.3.20i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sep 01, 2001 16:11 +0200, svetljo wrote: > clean Linus kernel-2.4.9 LVM-1.0.1rc1 ext2 and > reiserfs segfaults > clean linux-2.4.9-ac5 LVM-1.0 ext2 and > reiserfs segfaults > | linux-2.4.10-pre2-xfs LVM-1.0.1rc2 ext2 and > reiserfs segfaults, but xfs seems to work > | from SGI's cvs tree linux-2.4-xfs taken today in > the early morning Is it possible that you are having memory problems? Did this work with earlier kernels and it now only fails with 2.4.9? Have you tried running with memtest86 to check your RAM? It seems like you are having too many problems with different filesystems. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert From owner-linux-xfs@oss.sgi.com Mon Sep 3 20:59:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f843x9Q09254 for linux-xfs-outgoing; Mon, 3 Sep 2001 20:59:09 -0700 Received: from alaska.net (kitsune.nwc.alaska.net [209.112.130.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f843x4d09235 for ; Mon, 3 Sep 2001 20:59:04 -0700 Received: from erbenson.alaska.net (34-pm21.nwc.alaska.net [209.112.143.34]) by alaska.net (8.9.1/8.9.1) with ESMTP id TAA10597 for ; Mon, 3 Sep 2001 19:58:54 -0800 (AKDT) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 07583397B for ; Mon, 3 Sep 2001 19:45:37 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id B091110246; Mon, 3 Sep 2001 19:45:37 -0800 (AKDT) Date: Mon, 3 Sep 2001 19:45:37 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: kernel spam when mounting xfs Message-ID: <20010903194537.G14519@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Sw7tCqrGA+HQ0/zt" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-OS: Debian GNU Mail-Copies-To: nobody Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --Sw7tCqrGA+HQ0/zt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, i just recently converted a machine to use xfs on all partitions sans /boot. =20 the only thing i really dislike about it is all the spam from the kernel when the filesystems are mounted: Start mounting filesystem: ide0(3,5) Ending clean XFS mount for filesystem: ide0(3,5) =2E... and so on .... when you have several filesystems (i prefer to keep / /var /home and /usr split) this is rather messy. I also prefer the old axiom of `No news is good news' that is, if the filesystem mounts without errors, and was clean, i don't need to be told that.=20 so my suggestion is to eliminate the `Start mounting filesystem...' message altogether (its useless IMHO) and eliminate the `Ending clean mount' instead only display a (single) message if filesystem recovery was required. perhaps make a mount option, verbose, if some people prefer to see all these messages on filesystem mount. =20 note i have debug mode turned off in my kernel config. =20 thanks --=20 Ethan Benson http://www.alaska.net/~erbenson/ --Sw7tCqrGA+HQ0/zt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuUTmEACgkQJKx7GixEevyvbACghnIDBAUcGgIdB3KFJUzXF89B u1AAnRysvJpwqpOOpbMKQhFu63OvdM1U =zBjU -----END PGP SIGNATURE----- --Sw7tCqrGA+HQ0/zt-- From owner-linux-xfs@oss.sgi.com Mon Sep 3 23:54:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f846shB11840 for linux-xfs-outgoing; Mon, 3 Sep 2001 23:54:43 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f846sbd11817 for ; Mon, 3 Sep 2001 23:54:37 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA04960; Tue, 4 Sep 2001 08:54:35 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA28435; Tue, 4 Sep 2001 08:54:34 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 9EBF157306; Tue, 4 Sep 2001 08:53:23 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 4B95125835; Tue, 4 Sep 2001 08:53:23 +0200 (CEST) Message-ID: <3B947A63.F08A1245@ch.sauter-bc.com> Date: Tue, 04 Sep 2001 08:53:23 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Ethan Benson Cc: linux-xfs@oss.sgi.com Subject: Re: kernel spam when mounting xfs References: <20010903194537.G14519@plato.local.lan> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ethan Benson schrieb: > > Hi, > > i just recently converted a machine to use xfs on all partitions sans > /boot. > > the only thing i really dislike about it is all the spam from the > kernel when the filesystems are mounted: Is this spam? Did you ever use ReiserFS? Checking ReiserFS transaction log (device 03:06) ... Using r5 hash to sort names Primary Sponsor thresholdnetworks.com Raid Tuning sponsored by emusic.com HSM sponsored by bigstorage.com Alpha port and SMP sponsored by alpha-processor.com, alpha port by www.innovative-software.com and www.quant-x.com. ReiserFS version 3.5.29 VFS: Mounted root (reiserfs filesystem) readonly. change_root: old root has d_count=1 Trying to unmount old root ... okay Freeing unused kernel memory: 128k freed Adding Swap: 506008k swap-space (priority -1) Checking ReiserFS transaction log (device 03:01) ... Using r5 hash to sort names ReiserFS version 3.5.29 Checking ReiserFS transaction log (device 03:08) ... Using r5 hash to sort names ReiserFS version 3.5.29 Checking ReiserFS transaction log (device 03:07) ... Using r5 hash to sort names ReiserFS version 3.5.29 > > Start mounting filesystem: ide0(3,5) > Ending clean XFS mount for filesystem: ide0(3,5) > .... and so on .... > > when you have several filesystems (i prefer to keep / /var /home and > /usr split) this is rather messy. I also prefer the old axiom of `No > news is good news' that is, if the filesystem mounts without errors, > and was clean, i don't need to be told that. > > so my suggestion is to eliminate the `Start mounting filesystem...' > message altogether (its useless IMHO) and eliminate the `Ending clean > mount' instead only display a (single) message if filesystem recovery > was required. > > perhaps make a mount option, verbose, if some people prefer to see all > these messages on filesystem mount. > > note i have debug mode turned off in my kernel config. > > thanks > > -- > Ethan Benson > http://www.alaska.net/~erbenson/ > > ------------------------------------------------------------------------ > Part 1.2Type: application/pgp-signature From owner-linux-xfs@oss.sgi.com Tue Sep 4 00:03:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8473N012106 for linux-xfs-outgoing; Tue, 4 Sep 2001 00:03:23 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8473Gd12087; Tue, 4 Sep 2001 00:03:16 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id JAA06610; Tue, 4 Sep 2001 09:03:14 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id JAA29065; Tue, 4 Sep 2001 09:03:13 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id B2A7357306; Tue, 4 Sep 2001 09:02:20 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 4A34825835; Tue, 4 Sep 2001 09:02:20 +0200 (CEST) Message-ID: <3B947C7C.7E44DC92@ch.sauter-bc.com> Date: Tue, 04 Sep 2001 09:02:20 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Michael Wahlbrink Cc: Keith Owens , Seth Mos , linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Michael Wahlbrink schrieb: > > On 02.09.2001 00:07:42 "Michael Wahlbrink" wrote: > >Ok, no problem ;-) > > > >I'll make my tests with ext2 to see if the kernel 'oopses' too......... > >And the PII is still compiling th xfs kernel.... > > > >cu > >michael > > > Ok, I think I've found the error! :-)) > I've made the tests also with ext2 and run into IO errors...... I checked > the drives and burned my fingers...... The drives are getting to hot :-( > So I installed a additional cooler and all was nearly fine... > Because of all the compilation tries and tests my system was unusuable and > i get more and more strange errors (also from xfs)...... So i installed a > new clean system (2.4.10-pre4-xfs), and now its working.......! > On the PII its also working fine..... > > But there is one thing, why does ext2 says that it have IO Problems when > writing to disk and xfs simply dies with an oops when you try to acess the > corrupt data ???? Just imagine you have bad memory, it is flipping bits sometimes. Now can you ask why does it crash when using this or another filesystem? No, I mean the filesystems just expect properly working hardware. If there is a problem with corruption, you can not expect reproducable effects. My own experience with corruption was that most time xfs survived without oopsing. But anyway such a system is unusable. 1 must be 1, and 0 must be 0. Simon > > cu > michael -- Simon Matter Tel: +41 61 695 57 35 Fr.Sauter AG / CIT Fax: +41 61 695 53 30 Im Surinam 55 CH-4016 Basel [mailto:simon.matter@ch.sauter-bc.com] From owner-linux-xfs@oss.sgi.com Tue Sep 4 00:04:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8474mC12256 for linux-xfs-outgoing; Tue, 4 Sep 2001 00:04:48 -0700 Received: from rebel.net.au (IDENT:root@rebel.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8474id12237 for ; Tue, 4 Sep 2001 00:04:44 -0700 Received: from rebel.net.au (dialup-6.rebel.net.au [203.20.69.76]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id QAA32157; Tue, 4 Sep 2001 16:34:09 +0930 Message-ID: <3B947E6F.A45A65D2@rebel.net.au> Date: Tue, 04 Sep 2001 16:40:39 +0930 From: David Lloyd X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Simon Matter CC: Ethan Benson , linux-xfs@oss.sgi.com Subject: Re: kernel spam when mounting xfs References: <20010903194537.G14519@plato.local.lan> <3B947A63.F08A1245@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Heh! > Is this spam? Did you ever use ReiserFS? > > Checking ReiserFS transaction log (device 03:06) ... > Using r5 hash to sort names > Primary Sponsor thresholdnetworks.com > Raid Tuning sponsored by emusic.com > HSM sponsored by bigstorage.com > Alpha port and SMP sponsored by alpha-processor.com, alpha port by > www.innovative-software.com and www.quant-x.com. If you search the ReiserFS mailing list there was an absolute flame war about this very matter ;-P DSL -- Pussy's good for six at the most (Mrs. Lovett, Sweeney Todd) From owner-linux-xfs@oss.sgi.com Tue Sep 4 01:19:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f848JmP13582 for linux-xfs-outgoing; Tue, 4 Sep 2001 01:19:48 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f848IMd13544; Tue, 4 Sep 2001 01:18:22 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id E7E9767040; Tue, 4 Sep 2001 10:18:10 +0200 (CEST) To: Simon Matter Cc: Keith Owens , Seth Mos , linux-xfs@oss.sgi.com, Michael Wahlbrink , owner-linux-xfs@oss.sgi.com Subject: Re: Kernel Oops ..... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Tue, 4 Sep 2001 10:18:09 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 04.09.2001 10:18:20, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 04.09.2001 10:18:20, Serialize complete at 04.09.2001 10:18:20, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 04.09.2001 10:18:20, S/MIME Sign complete at 04.09.2001 10:18:20, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 04.09.2001 10:18:11, Serialize complete at 04.09.2001 10:18:11 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z46341_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z46341_boundary_sign Content-Type: text/plain; charset="us-ascii" On 04.09.2001 09:02:20 Simon Matter wrote: >Michael Wahlbrink schrieb: >> >> On 02.09.2001 00:07:42 "Michael Wahlbrink" wrote: >> >Ok, no problem ;-) >> > >> >I'll make my tests with ext2 to see if the kernel 'oopses' >too......... >> >And the PII is still compiling th xfs kernel.... >> > >> >cu >> >michael >> > >> Ok, I think I've found the error! :-)) >> I've made the tests also with ext2 and run into IO errors...... I >checked >> the drives and burned my fingers...... The drives are getting to hot >:-( >> So I installed a additional cooler and all was nearly fine... >> Because of all the compilation tries and tests my system was >unusuable and >> i get more and more strange errors (also from xfs)...... So i >installed a >> new clean system (2.4.10-pre4-xfs), and now its working.......! >> On the PII its also working fine..... >> >> But there is one thing, why does ext2 says that it have IO Problems >when >> writing to disk and xfs simply dies with an oops when you try to >acess the >> corrupt data ???? > >Just imagine you have bad memory, it is flipping bits sometimes. Now can >you ask why does it crash when using this or another filesystem? No, I >mean the filesystems just expect properly working hardware. If there is >a problem with corruption, you can not expect reproducable effects. My >own experience with corruption was that most time xfs survived without >oopsing. But anyway such a system is unusable. 1 must be 1, and 0 must >be 0. I think it was the temperature, cause the SDRAM was checked one night long with memtest86 without errors, and also for a test replaced with other DIMMs which worked fine in another Mashine and are also correct........ cu micha ---------z46341_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM1MIICHaADAgECAgQ68WMUMA0GCSqGSIb3DQEBBAUAMIGeMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYDVQQLExdDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNz IDIgQ0EwHhcNMDEwNTAzMDAwMDAwWhcNMDIwNTAzMjM1OTAwWjCBnTELMAkGA1UE BhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgG A1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEaMBgGA1UEAxMR TWljaGFlbCBXYWhsYnJpbmsxIjAgBgkqhkiG9w0BCQEWE21pd0Bwcm9wYWNrLWRh dGEuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALIOckqT1A9Rhsfgt4Y0 A98B9yUW0jztpCFpnti1cj5hkjaB7bTj029ki6cVXwlmv/MzqrIB0AfqOhILTDOo OilUqAjydR5D88jKnLPT1JyIKOaMjjFWa26vmSB2lTp4RdPmbtkiQoUZ9cBvglMV FYL/b9gC6mEpLAAyAfV8pIrNAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAEZhuNN2 nawO0zgdlUS379E2LP1Y1UkqRvbs+JJt4o/9iICT9QtC1Xqfb2S1AUldHSrT83PW TUoNjpL+n/SYeDrq6UPkfCMrbO4XhwRcOy5b+xJG+5GfshrL0ENzBVF2SsSYWcoz cp6y0GAVI74Wf7W91QCPz4cyhr3AP7ASal15XjlXLyoNL+59AqD2elGWsU6OUCg8 qw2xG/2IYAcpMGgHpmab9OBtF4R8+2b9qnFDqWUPK+L6KjJpwPFvkYpgW4ESsW5L jQgfog9+/gB8GxFU1FXvcbnuaJFwudaq9wMyKiLWJIK0jVH5fUIUzEPOemOz8fhn zUNVTnhZVI/sF6wwggO6MIICoqADAgECAgQ5Td9zMA0GCSqGSIb3DQEBBAUAMIGe MQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYD VQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMSAwHgYD VQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBE YXRhIENsYXNzIDIgQ0EwHhcNMDAwNjE4MDAwMDAwWhcNMDIwNjE4MjM1OTAwWjCB njELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAG A1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEgR21iSDEgMB4G A1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sg RGF0YSBDbGFzcyAyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 4sC9VaqHbKulz8+2vUwsODP7NAtBFxlehMYd6zHoYgD67GKnTlQj0EKK+TtHfZvI VtPKBXo4xuwePOx34pS+yeg4Wu2Yt984UFvy5WGhaSOox5OTfQ040go0QP+GPcz/ 02q8sy/UKdEFH1Q7l4AMQoewr6mi12mSii2HudcA4oWBqshHrZG64TFbZ539M4Au DxFqxGISuozATaMw4UVzR4Jju7KUH+chhj7eTYxGr1a8Ov8xapOuSxwrR0Nm9qKl h1/b9tspuLC3wNP2SExBccmOOX1QPHI9uVOegkQX0kSFmL0kONzUIa9d9TAYyP5H /OazPHpKcb7evqyJh5gmNwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBMrCrpoVIi mshBQdBdtPVCBex75s8sb/qmPFwxTn8IHASc3AWtfBPmoEf1c5FcVUERLQFr6uQV RU5ejmJewyzzf+iKlGLjWPvWLghEibWm+GTm1rLJpe+YwgR6/5y874RhaUj3KFi7 yCJsUaF2qKgEv39Lq4VgdRihhB++ZF3zgj/dv7dwOwC2jgk8mAZf1Cp3jG8yhLnI ZIRbYOuZdUCpBzCRj1qfD+P4izFarG4sHo3k7kfkCzpsyDrCJojmXzzoF3diAm5Q PHWlYYhNA0i09m8hW9YpxhfBp7qmIIYd5tCOqjZVgiyA9RLb68a2PnS30LzIIsQH OtubyM8KT7WqAAAxgDCCAfgCAQEwgacwgZ4xCzAJBgNVBAYTAmRlMRswGQYDVQQI ExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEaMBgGA1UE ChMRUHJvcGFjayBEYXRhIEdtYkgxIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSAwHgYDVQQDExdQcm9wYWNrIERhdGEgQ2xhc3MgMiBDQQIEOvFjFDAJ BgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDkwNDA4MTgyMFowIwYJKoZIhvcNAQkEMRYEFBt+fAfpe7NDJFJu lcjDwz7RKtwXMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZIhvcNAwIC AgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGACysK+7ZUbvvpcfNiqAMykEqTmnYwMNYvWHfCtgLG+KrGUkGDlYb+ N6vRE+RLCQ5ZvYcYN0HCWoLedd3TByHoxtqQnBQjqtyalytIVDJ3ZOvK91l7rrt3 aC2bDv1Skw8Rf3CVekVI+pXMJeZAvZ1/nsHTeEaDzv36KRzCM2byh5wAAAAAAAAA AA== ---------z46341_boundary_sign-- From owner-linux-xfs@oss.sgi.com Tue Sep 4 02:06:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8496ww14370 for linux-xfs-outgoing; Tue, 4 Sep 2001 02:06:58 -0700 Received: from trna.ximian.com (trna.ximian.com [141.154.95.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8496ud14344 for ; Tue, 4 Sep 2001 02:06:56 -0700 Received: (from vladimir@localhost) by trna.ximian.com (8.9.3/8.9.3) id FAA17013; Tue, 4 Sep 2001 05:06:37 -0400 Date: Tue, 4 Sep 2001 05:06:37 -0400 From: Vladimir Vukicevic To: David Lloyd Cc: Simon Matter , Ethan Benson , linux-xfs@oss.sgi.com Subject: Re: kernel spam when mounting xfs Message-ID: <20010904050637.A16701@ximian.com> References: <20010903194537.G14519@plato.local.lan> <3B947A63.F08A1245@ch.sauter-bc.com> <3B947E6F.A45A65D2@rebel.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B947E6F.A45A65D2@rebel.net.au>; from lloy0076@rebel.net.au on Tue, Sep 04, 2001 at 04:40:39PM +0930 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Sep 04, 2001 at 04:40:39PM +0930, David Lloyd wrote: > > Checking ReiserFS transaction log (device 03:06) ... > > Using r5 hash to sort names > > Primary Sponsor thresholdnetworks.com > > Raid Tuning sponsored by emusic.com > > HSM sponsored by bigstorage.com > > Alpha port and SMP sponsored by alpha-processor.com, alpha port by > > www.innovative-software.com and www.quant-x.com. > > If you search the ReiserFS mailing list there was an absolute flame war > about this very matter ;-P Isn't everything on the ReiserFS mailing list a flame of some form or another? :-) :-) :-) - Vlad From owner-linux-xfs@oss.sgi.com Tue Sep 4 02:15:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f849Fdt14625 for linux-xfs-outgoing; Tue, 4 Sep 2001 02:15:39 -0700 Received: from alaska.net (sephiroth.nwc.alaska.net [209.112.130.27]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f849FYd14606 for ; Tue, 4 Sep 2001 02:15:34 -0700 Received: from erbenson.alaska.net (34-pm21.nwc.alaska.net [209.112.143.34]) by alaska.net (8.11.5/8.11.5) with ESMTP id f849FVP03311 for ; Tue, 4 Sep 2001 01:15:32 -0800 (AKDT) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 79DD7397B for ; Tue, 4 Sep 2001 01:15:30 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 47BC110246; Tue, 4 Sep 2001 01:15:30 -0800 (AKDT) Date: Tue, 4 Sep 2001 01:15:30 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: kernel spam when mounting xfs Message-ID: <20010904011530.I14519@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20010903194537.G14519@plato.local.lan> <3B947A63.F08A1245@ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/GPgYEyhnw15BExa" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B947A63.F08A1245@ch.sauter-bc.com>; from simon.matter@ch.sauter-bc.com on Tue, Sep 04, 2001 at 08:53:23AM +0200 X-OS: Debian GNU Mail-Copies-To: nobody Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --/GPgYEyhnw15BExa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 04, 2001 at 08:53:23AM +0200, Simon Matter wrote: > Ethan Benson schrieb: > >=20 > > Hi, > >=20 > > i just recently converted a machine to use xfs on all partitions sans > > /boot. > >=20 > > the only thing i really dislike about it is all the spam from the > > kernel when the filesystems are mounted: >=20 > Is this spam? Did you ever use ReiserFS? no i prefer to use filesystems that runs on archetectures other then i386 ;-) > Checking ReiserFS transaction log (device 03:06) ... > Using r5 hash to sort names > Primary Sponsor thresholdnetworks.com > Raid Tuning sponsored by emusic.com > HSM sponsored by bigstorage.com > Alpha port and SMP sponsored by alpha-processor.com, alpha port by > www.innovative-software.com and www.quant-x.com. > ReiserFS version 3.5.29 > VFS: Mounted root (reiserfs filesystem) readonly. > change_root: old root has d_count=3D1 > Trying to unmount old root ... okay > Freeing unused kernel memory: 128k freed > Adding Swap: 506008k swap-space (priority -1) > Checking ReiserFS transaction log (device 03:01) ... > Using r5 hash to sort names > ReiserFS version 3.5.29 > Checking ReiserFS transaction log (device 03:08) ... > Using r5 hash to sort names > ReiserFS version 3.5.29 > Checking ReiserFS transaction log (device 03:07) ... > Using r5 hash to sort names > ReiserFS version 3.5.29 ok thats bad (ya reason not to use reiserfs...). but still my request stands. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --/GPgYEyhnw15BExa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuUm7IACgkQJKx7GixEevxWGwCeMc4U3A6fIS6V5oxtNLNWFwR8 IcoAn1A/AyuRGl4DH37RCNd6jOzmgze2 =Cwo7 -----END PGP SIGNATURE----- --/GPgYEyhnw15BExa-- From owner-linux-xfs@oss.sgi.com Tue Sep 4 04:41:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84BfCM17200 for linux-xfs-outgoing; Tue, 4 Sep 2001 04:41:12 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84Bf9d17181 for ; Tue, 4 Sep 2001 04:41:09 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f84Bf3523571 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 4 Sep 2001 04:41:03 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id NAA861257 for ; Tue, 4 Sep 2001 13:41:03 +0200 (CEST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id VAA08035 for linux-xfs@oss.sgi.com; Tue, 4 Sep 2001 21:39:42 +1000 (EST) Date: Tue, 4 Sep 2001 21:39:42 +1000 (EST) From: Nathan Scott Message-Id: <200109041139.VAA08035@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - mount msgs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Consensus seems to be less chatty on mount - this should do the trick. Can still get at these messages with a debug build (as is the case for the nightly QA runs) where these messages are still quite useful. cheers. Date: Tue Sep 4 04:36:44 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/attr-linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102087a linux/fs/xfs/xfs_log.c - 1.240 linux/fs/xfs/xfs_log_recover.c - 1.209 - only report clean log mounts in debug mode. linux/fs/xfs_support/debug.c - 1.3 - make debug mode cmn_err only print out messages in debug kernels. From owner-linux-xfs@oss.sgi.com Tue Sep 4 04:44:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84Biv117371 for linux-xfs-outgoing; Tue, 4 Sep 2001 04:44:57 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84Bisd17352 for ; Tue, 4 Sep 2001 04:44:54 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id A46D51E11C; Tue, 4 Sep 2001 13:44:48 +0200 (MEST) Date: Tue, 4 Sep 2001 13:44:37 +0200 From: Andi Kleen To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - mount msgs Message-ID: <20010904134437.A28205@gruyere.muc.suse.de> References: <200109041139.VAA08035@snort.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200109041139.VAA08035@snort.melbourne.sgi.com>; from nathans@snort.melbourne.sgi.com on Tue, Sep 04, 2001 at 09:39:42PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Sep 04, 2001 at 09:39:42PM +1000, Nathan Scott wrote: > Consensus seems to be less chatty on mount - this should do the trick. > Can still get at these messages with a debug build (as is the case for > the nightly QA runs) where these messages are still quite useful. I think it would be better to keep them; as it makes debugging even on production machines easier. -Andi From owner-linux-xfs@oss.sgi.com Tue Sep 4 04:53:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84Br5117614 for linux-xfs-outgoing; Tue, 4 Sep 2001 04:53:05 -0700 Received: from ender.capfed1.sinectis.com.ar (IDENT:root@ender.capfed1.sinectis.com.ar [216.244.211.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84Br0d17594 for ; Tue, 4 Sep 2001 04:53:00 -0700 Received: from sinectis.com (ix.sinectis.com.ar [216.244.192.24]) by ender.capfed1.sinectis.com.ar (8.9.3/8.9.3) with ESMTP id IAA25261 for ; Tue, 4 Sep 2001 08:52:58 -0300 Message-ID: <3B94BFD9.83E09CEE@sinectis.com> Date: Tue, 04 Sep 2001 08:49:45 -0300 From: Dario Brignardello Organization: Sinectis S.A. X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.4.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: Block size. Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms3AAA66B764624A336696086E" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms3AAA66B764624A336696086E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all: Sorry for bother with a newbie question, but I didn't find the answer in the FAQ:-). I would like to now the reasons (technically speaking) for the max block size to be fixed at 4K in linux, since, as stated in the white papers, XFS is designed to support larger block sizes, and it was one of the reasons that made it the difference when I had to choose a journaling filesystem. Thanks a lot for your time. Regards! Dario Brignardello --------------ms3AAA66B764624A336696086E Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIHKAYJKoZIhvcNAQcCoIIHGTCCBxUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BXEwggJAMIIBqaADAgECAgMEPIQwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTAyMjExNzA3MjZaFw0wMjAyMjExNzA3MjZa MEcxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxJDAiBgkqhkiG9w0BCQEWFWRi cmlnbmFyQHNpbmVjdGlzLmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCn/IthgAlkAIa6 +dZyjp+6U06kxrHJKPfRAJM/1YJeiTY5vjHq4fMdrUaF/tkd90V4H10aO7FK2B0+KV5odlRJ AgMBAAGjMjAwMCAGA1UdEQQZMBeBFWRicmlnbmFyQHNpbmVjdGlzLmNvbTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBABaZqSGHw4VZbOeZRUKqPbPqTNv3f5D6OX0x3kJX0nZq 2gLRExP7rhWGTxjtIoLr7+PvOyt2E/p4CQpy/zjHtoqATT4Nl5DM6Oz0ywsi2TW6Zxvog0gO G+AVS+UBdIvqO8Bat/bX633X10ibTH41Yh1pQ0T5SnLD1i/bis2EqbQIMIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYIBfzCCAXsC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBDyEMAkG BSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w MTA5MDQxMTQ5NDZaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZIhvcNAwICASgwIwYJKoZIhvcN AQkEMRYEFOdTigqqhhe10klBwEZBBCVfN674MA0GCSqGSIb3DQEBAQUABEChZnqjeGBBM4rt GbS3swQTXFRLJsqqfL5Fz4n/Vh4+wBhyG5Wy5NWWAGzw8v8IZaSgOVACjVRsHyJWkh3l+irV --------------ms3AAA66B764624A336696086E-- From owner-linux-xfs@oss.sgi.com Tue Sep 4 04:54:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84BsrY17763 for linux-xfs-outgoing; Tue, 4 Sep 2001 04:54:53 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84Bsod17744 for ; Tue, 4 Sep 2001 04:54:50 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f84Bsi524529 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 4 Sep 2001 04:54:44 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id NAA875744 for ; Tue, 4 Sep 2001 13:54:44 +0200 (CEST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA29632; Tue, 4 Sep 2001 22:53:24 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id WAA63648; Tue, 4 Sep 2001 22:53:23 +1100 (AEDT) Date: Tue, 4 Sep 2001 22:53:23 +1100 From: Nathan Scott To: Andi Kleen Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - mount msgs Message-ID: <20010904225323.A344731@wobbly.melbourne.sgi.com> References: <200109041139.VAA08035@snort.melbourne.sgi.com> <20010904134437.A28205@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010904134437.A28205@gruyere.muc.suse.de>; from ak@suse.de on Tue, Sep 04, 2001 at 01:44:37PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Andi, On Tue, Sep 04, 2001 at 01:44:37PM +0200, Andi Kleen wrote: > On Tue, Sep 04, 2001 at 09:39:42PM +1000, Nathan Scott wrote: > > Consensus seems to be less chatty on mount - this should do the trick. > > Can still get at these messages with a debug build (as is the case for > > the nightly QA runs) where these messages are still quite useful. > > I think it would be better to keep them; as it makes debugging even on > production machines easier. > _Now_ you pipe up! Well, I don't think the "finished clean mount" message is particularly useful, but I'll put the initial message back in at the start of a mount, I think, so that in the normal case its just one message per mount. If anyone else really wants the message at the end of a clean mount, I guess I can put that back too... cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Sep 4 05:26:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84CQKt18450 for linux-xfs-outgoing; Tue, 4 Sep 2001 05:26:20 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84CQFd18429 for ; Tue, 4 Sep 2001 05:26:15 -0700 Received: (qmail 28738 invoked from network); 4 Sep 2001 12:26:11 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 4 Sep 2001 12:26:11 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 2ECE8300090; Tue, 4 Sep 2001 22:25:29 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id D0EA39E; Tue, 4 Sep 2001 22:25:29 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Dario Brignardello Cc: "linux-xfs@oss.sgi.com" Subject: Re: Block size. In-reply-to: Your message of "Tue, 04 Sep 2001 08:49:45 -0300." <3B94BFD9.83E09CEE@sinectis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Sep 2001 22:25:24 +1000 Message-ID: <11089.999606324@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 04 Sep 2001 08:49:45 -0300, Dario Brignardello wrote: > Sorry for bother with a newbie question, but I didn't find the >answer in the FAQ:-). I would like to now the reasons (technically >speaking) for the max block size to be fixed at 4K in linux It is a restriction of the Linux VM subsystem, at the moment file block size must equal hardware page size. There is work in progress to remove the restriction, but it is kernel 2.5 code. From owner-linux-xfs@oss.sgi.com Tue Sep 4 05:32:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84CWPR18661 for linux-xfs-outgoing; Tue, 4 Sep 2001 05:32:25 -0700 Received: from alaska.net (sephiroth.nwc.alaska.net [209.112.130.27]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84CWLd18640 for ; Tue, 4 Sep 2001 05:32:21 -0700 Received: from erbenson.alaska.net (34-pm21.nwc.alaska.net [209.112.143.34]) by alaska.net (8.11.5/8.11.5) with ESMTP id f84CWIP17773 for ; Tue, 4 Sep 2001 04:32:19 -0800 (AKDT) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 4E574397B for ; Tue, 4 Sep 2001 04:32:17 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 7411C10246; Tue, 4 Sep 2001 04:32:17 -0800 (AKDT) Date: Tue, 4 Sep 2001 04:32:17 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: TAKE - mount msgs Message-ID: <20010904043217.U14519@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200109041139.VAA08035@snort.melbourne.sgi.com> <20010904134437.A28205@gruyere.muc.suse.de> <20010904225323.A344731@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zd8I2GZVcdxtyaG/" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010904225323.A344731@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Tue, Sep 04, 2001 at 10:53:23PM +1100 X-OS: Debian GNU Mail-Copies-To: nobody Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --Zd8I2GZVcdxtyaG/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 04, 2001 at 10:53:23PM +1100, Nathan Scott wrote: > hi Andi, >=20 > On Tue, Sep 04, 2001 at 01:44:37PM +0200, Andi Kleen wrote: > > On Tue, Sep 04, 2001 at 09:39:42PM +1000, Nathan Scott wrote: > > > Consensus seems to be less chatty on mount - this should do the trick. > > > Can still get at these messages with a debug build (as is the case for > > > the nightly QA runs) where these messages are still quite useful. > >=20 > > I think it would be better to keep them; as it makes debugging even on > > production machines easier. > >=20 >=20 > _Now_ you pipe up! Well, I don't think the "finished clean mount" > message is particularly useful, but I'll put the initial message > back in at the start of a mount, I think, so that in the normal case > its just one message per mount. please don't, or make it a compile time option. it makes an ugly mess of boot messages and clutters the logs with really useless data. > If anyone else really wants the message at the end of a clean mount, > I guess I can put that back too... make it a compile time option if some people want it. =20 CONFIG_VERBOSE_MOUNT or something. =20 no news is good news. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --Zd8I2GZVcdxtyaG/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuUydEACgkQJKx7GixEevyG4ACcDH9s1dShiMpC2JTs+w2HPIcC wz8AoJhahpiIdsvbnF9qJvWZ2ZBxTSUO =UPrn -----END PGP SIGNATURE----- --Zd8I2GZVcdxtyaG/-- From owner-linux-xfs@oss.sgi.com Tue Sep 4 05:39:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84Cdx218987 for linux-xfs-outgoing; Tue, 4 Sep 2001 05:39:59 -0700 Received: from alaska.net (sephiroth.nwc.alaska.net [209.112.130.27]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84Cdtd18968 for ; Tue, 4 Sep 2001 05:39:56 -0700 Received: from erbenson.alaska.net (34-pm21.nwc.alaska.net [209.112.143.34]) by alaska.net (8.11.5/8.11.5) with ESMTP id f84CdrP18274 for ; Tue, 4 Sep 2001 04:39:54 -0800 (AKDT) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 7AB6E397B for ; Tue, 4 Sep 2001 04:39:52 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id BD6FD10246; Tue, 4 Sep 2001 04:39:52 -0800 (AKDT) Date: Tue, 4 Sep 2001 04:39:52 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: smaller mkfs.xfs Message-ID: <20010904043952.V14519@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JaUdphvQ2+4F/M7k" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-OS: Debian GNU Mail-Copies-To: nobody Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --JaUdphvQ2+4F/M7k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Is there any possible ways to reduce the size of the mkfs.xfs binary? =20 I am working on adding support for direct XFS installation to the Debian boot-floppies, but the size of mkfs.xfs is proving to be a real problem (we are already very tight on space as it is). =20 from what i can tell by briefly looking at it, libuuid appears to be statically linked into this binary? is this correct? making this dynamic would help a little (probably not much but i can use every kbyte i can get). also its built with -O1 optimization, is there any reason for this? would -Os be potentially problematic? --=20 Ethan Benson http://www.alaska.net/~erbenson/ --JaUdphvQ2+4F/M7k Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuUy5gACgkQJKx7GixEevz6swCeJtCYhPgXs6bazyJ3Oe+rYmai uNAAoI70TsNkyOa9epWSB0KzKxo4xaQc =eAD2 -----END PGP SIGNATURE----- --JaUdphvQ2+4F/M7k-- From owner-linux-xfs@oss.sgi.com Tue Sep 4 05:43:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84Chh119156 for linux-xfs-outgoing; Tue, 4 Sep 2001 05:43:43 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84Chdd19137 for ; Tue, 4 Sep 2001 05:43:40 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 316871E102; Tue, 4 Sep 2001 14:43:34 +0200 (MEST) Date: Tue, 4 Sep 2001 14:43:23 +0200 From: Andi Kleen To: Nathan Scott Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: TAKE - mount msgs Message-ID: <20010904144323.B29262@gruyere.muc.suse.de> References: <200109041139.VAA08035@snort.melbourne.sgi.com> <20010904134437.A28205@gruyere.muc.suse.de> <20010904225323.A344731@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010904225323.A344731@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Tue, Sep 04, 2001 at 10:53:23PM +1100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Sep 04, 2001 at 10:53:23PM +1100, Nathan Scott wrote: > hi Andi, > > On Tue, Sep 04, 2001 at 01:44:37PM +0200, Andi Kleen wrote: > > On Tue, Sep 04, 2001 at 09:39:42PM +1000, Nathan Scott wrote: > > > Consensus seems to be less chatty on mount - this should do the trick. > > > Can still get at these messages with a debug build (as is the case for > > > the nightly QA runs) where these messages are still quite useful. > > > > I think it would be better to keep them; as it makes debugging even on > > production machines easier. > > > > _Now_ you pipe up! Well, I don't think the "finished clean mount" > message is particularly useful, but I'll put the initial message > back in at the start of a mount, I think, so that in the normal case > its just one message per mount. Keeping the initial message only would be fine for me. -Andi From owner-linux-xfs@oss.sgi.com Tue Sep 4 05:46:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84Ckd519332 for linux-xfs-outgoing; Tue, 4 Sep 2001 05:46:39 -0700 Received: from mailin3.email.bigpond.com (juicer24.bigpond.com [139.134.6.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84CkZd19310 for ; Tue, 4 Sep 2001 05:46:35 -0700 Received: from HERCULES ([144.135.24.87]) by mailin3.email.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GJ52FP00.IUG for ; Tue, 4 Sep 2001 22:52:37 +1000 Received: from CPE-61-9-143-213.vic.bigpond.net.au ([61.9.143.213]) by bwmam07.mailsvc.email.bigpond.com(MailRouter V2.9i 8347/3792041); 04 Sep 2001 22:52:37 Content-Type: text/plain; charset="iso-8859-1" From: AKH To: linux-xfs@oss.sgi.com Subject: Re: about to try RAID.... Date: Tue, 4 Sep 2001 22:46:25 +1000 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01090422462501.03514@HERCULES> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk If you think getting 3ware controllers are hard in the UK - try getting them in Australia. The only way I got mine was to get it at the Asian distributor in Singapore when I was there on business. I'm in the process of doing exactly the same thing as you. At the moment at work I have 2 server machines running stress/benchmark tests - mongo.pl & bonie++. The tests have only been running for a day but so far the 3ware controller has died on all 3 attempts at mongo.pl (but passes bonnie++), whereas the machine running the 2 Promise TX2 controllers has not missed a beat. I still have quite a few more tests before I put either of them into service but so far it looks good for the Promise controllers. The machine's specs: Machine #1 Athlon 1.333 ASUS A7V-133-C 256M SDRAM 5 IBM 20G (IC35L020AVER07-0 from both Thailand & Philippines from May onwards) 2 Promise TX2 IDE controllers Machine #2 Same as above except the 3ware controller (4 port 6000 series) I did have problems with the Promise TX2 controllers before Kernel 2.4.7 I had to use -ac patches to get the things to run at all. Now I'm using 2.4.9 without -ac patches. However, I have noticed a couple of lines of code difference between the vanilla 2.4.9 and the 2.4.9-ac5 with regards to the Promise driver. (Not sure what the differences really does yet). It appears these days you really have to test your hardware well yourself to be able to sleep soundly at night. Adrian Head From owner-linux-xfs@oss.sgi.com Tue Sep 4 05:48:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84CmBc19496 for linux-xfs-outgoing; Tue, 4 Sep 2001 05:48:11 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84Cm8d19477 for ; Tue, 4 Sep 2001 05:48:09 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 463601E101; Tue, 4 Sep 2001 14:48:03 +0200 (MEST) Date: Tue, 4 Sep 2001 14:47:31 +0200 From: Andi Kleen To: Keith Owens Cc: Dario Brignardello , "linux-xfs@oss.sgi.com" Subject: Re: Block size. Message-ID: <20010904144731.A29342@gruyere.muc.suse.de> References: <3B94BFD9.83E09CEE@sinectis.com> <11089.999606324@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <11089.999606324@ocs3.intra.ocs.com.au>; from kaos@melbourne.sgi.com on Tue, Sep 04, 2001 at 10:25:24PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Sep 04, 2001 at 10:25:24PM +1000, Keith Owens wrote: > On Tue, 04 Sep 2001 08:49:45 -0300, > Dario Brignardello wrote: > > Sorry for bother with a newbie question, but I didn't find the > >answer in the FAQ:-). I would like to now the reasons (technically > >speaking) for the max block size to be fixed at 4K in linux > > It is a restriction of the Linux VM subsystem, at the moment file block > size must equal hardware page size. There is work in progress to > remove the restriction, but it is kernel 2.5 code. Minor correction: it must be smaller or equal hardware block size. -Andi From owner-linux-xfs@oss.sgi.com Tue Sep 4 06:21:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84DLLV20172 for linux-xfs-outgoing; Tue, 4 Sep 2001 06:21:21 -0700 Received: from alaska.net (kitsune.nwc.alaska.net [209.112.130.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84DLId20153 for ; Tue, 4 Sep 2001 06:21:18 -0700 Received: from erbenson.alaska.net (34-pm21.nwc.alaska.net [209.112.143.34]) by alaska.net (8.9.1/8.9.1) with ESMTP id FAA22070 for ; Tue, 4 Sep 2001 05:21:16 -0800 (AKDT) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id C6BA1397B for ; Tue, 4 Sep 2001 05:21:13 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id C116610246; Tue, 4 Sep 2001 05:21:13 -0800 (AKDT) Date: Tue, 4 Sep 2001 05:21:13 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: TAKE - mount msgs Message-ID: <20010904052113.X14519@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200109041139.VAA08035@snort.melbourne.sgi.com> <20010904134437.A28205@gruyere.muc.suse.de> <20010904225323.A344731@wobbly.melbourne.sgi.com> <20010904144323.B29262@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PxDrs/Fpf4pPiewX" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010904144323.B29262@gruyere.muc.suse.de>; from ak@suse.de on Tue, Sep 04, 2001 at 02:43:23PM +0200 X-OS: Debian GNU Mail-Copies-To: nobody Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --PxDrs/Fpf4pPiewX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 04, 2001 at 02:43:23PM +0200, Andi Kleen wrote: > Keeping the initial message only would be fine for me. why? at least on debian mount is called with -v which prints its own (more informative) mounting message --=20 Ethan Benson http://www.alaska.net/~erbenson/ --PxDrs/Fpf4pPiewX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuU1UkACgkQJKx7GixEevyAcACbBujc1WR9O1tSpkhnd8yGE9m0 PGsAniE9YFqEXkMzy7UswHQjZcnhxol7 =RJfH -----END PGP SIGNATURE----- --PxDrs/Fpf4pPiewX-- From owner-linux-xfs@oss.sgi.com Tue Sep 4 06:23:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84DNBV20327 for linux-xfs-outgoing; Tue, 4 Sep 2001 06:23:11 -0700 Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.127.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84DN6d20308 for ; Tue, 4 Sep 2001 06:23:06 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp3.xs4all.nl (8.9.3/8.9.3) with ESMTP id PAA10370; Tue, 4 Sep 2001 15:23:00 +0200 (CEST) Message-Id: <4.3.2.7.2.20010904152044.035d3b48@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Sep 2001 15:23:12 +0200 To: Ethan Benson , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: TAKE - mount msgs In-Reply-To: <20010904043217.U14519@plato.local.lan> References: <20010904225323.A344731@wobbly.melbourne.sgi.com> <200109041139.VAA08035@snort.melbourne.sgi.com> <20010904134437.A28205@gruyere.muc.suse.de> <20010904225323.A344731@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 04:32 4-9-2001 -0800, Ethan Benson wrote: >On Tue, Sep 04, 2001 at 10:53:23PM +1100, Nathan Scott wrote: > > hi Andi, > >=20 > > On Tue, Sep 04, 2001 at 01:44:37PM +0200, Andi Kleen wrote: > > > On Tue, Sep 04, 2001 at 09:39:42PM +1000, Nathan Scott wrote: > > > > Consensus seems to be less chatty on mount - this should do the trick. > > > > Can still get at these messages with a debug build (as is the case for > > > > the nightly QA runs) where these messages are still quite useful. > > >=20 > > > I think it would be better to keep them; as it makes debugging even on > > > production machines easier. > > >=20 > >=20 > > _Now_ you pipe up! Well, I don't think the "finished clean mount" > > message is particularly useful, but I'll put the initial message > > back in at the start of a mount, I think, so that in the normal case > > its just one message per mount. > >please don't, or make it a compile time option. it makes an ugly mess >of boot messages and clutters the logs with really useless data. > > > If anyone else really wants the message at the end of a clean mount, > > I guess I can put that back too... > >make it a compile time option if some people want it. =20 > >CONFIG_VERBOSE_MOUNT or something. =20 > >no news is good news. I like having at least one message that it mounted a certain fs. I can then use dmesg to see if it actually worked, and if it needs to recover or if it fails I like to see it as well. One line is enough. What I don't know is if you could stick these messages on one line. So the first mounting message without a \n and the succes or fail message after it. Don't know if it lets us do that. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Sep 4 06:31:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84DVQp20589 for linux-xfs-outgoing; Tue, 4 Sep 2001 06:31:26 -0700 Received: from alaska.net (sephiroth.nwc.alaska.net [209.112.130.27]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84DVLd20569 for ; Tue, 4 Sep 2001 06:31:21 -0700 Received: from erbenson.alaska.net (75-pm18.nwc.alaska.net [209.112.142.75]) by alaska.net (8.11.5/8.11.5) with ESMTP id f84DVJP22019 for ; Tue, 4 Sep 2001 05:31:19 -0800 (AKDT) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 083D3397B for ; Tue, 4 Sep 2001 05:31:17 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id B873C10246; Tue, 4 Sep 2001 05:31:17 -0800 (AKDT) Date: Tue, 4 Sep 2001 05:31:17 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: TAKE - mount msgs Message-ID: <20010904053117.Y14519@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20010904225323.A344731@wobbly.melbourne.sgi.com> <200109041139.VAA08035@snort.melbourne.sgi.com> <20010904134437.A28205@gruyere.muc.suse.de> <20010904225323.A344731@wobbly.melbourne.sgi.com> <20010904043217.U14519@plato.local.lan> <4.3.2.7.2.20010904152044.035d3b48@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SzQ167Kp6Zo0TWVn" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010904152044.035d3b48@pop.xs4all.nl>; from knuffie@xs4all.nl on Tue, Sep 04, 2001 at 03:23:12PM +0200 X-OS: Debian GNU Mail-Copies-To: nobody Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --SzQ167Kp6Zo0TWVn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 04, 2001 at 03:23:12PM +0200, Seth Mos wrote: > >no news is good news. >=20 > I like having at least one message that it mounted a certain fs. I can th= en=20 > use dmesg to see if it actually worked, and if it needs to recover or if = it=20 > fails I like to see it as well. running mount will also tell you that it worked. =20 as for recovery, i have always said leave the message mentioning that recovery was needed, i want to know that. but if no recovery was needed, and nothing went wrong then nothing should be printed at all. the lack of news is telling me everything was fine. =20 just like rm does not say `Sucessfully unlinked file: /blah' for everything it removes, it only prints something if there was a problem, eg: permission denied, readonly filesystem, or whatever. or in this case: rm: Starting unlink of file: /blah rm: Successfully unlinked file: /blah > One line is enough. What I don't know is if you could stick these message= s=20 zero lines is enough on clean sucessful mounts ;-) > on one line. So the first mounting message without a \n and the succes or= =20 > fail message after it. >=20 > Don't know if it lets us do that. dunno maybe, but i still prefer not to see anything if all went well. so again, a compile time option perhaps? --=20 Ethan Benson http://www.alaska.net/~erbenson/ --SzQ167Kp6Zo0TWVn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuU16UACgkQJKx7GixEevyXQQCgodICl1EAEMqo7kWd+67KGFnj ab4An0HA0BV8Isqs2cCf70T2UAJJxJ+v =yKq3 -----END PGP SIGNATURE----- --SzQ167Kp6Zo0TWVn-- From owner-linux-xfs@oss.sgi.com Tue Sep 4 06:53:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84DrLi21075 for linux-xfs-outgoing; Tue, 4 Sep 2001 06:53:21 -0700 Received: from smtp7.xs4all.nl (smtp7.xs4all.nl [194.109.127.133]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84DrGd21055 for ; Tue, 4 Sep 2001 06:53:17 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp7.xs4all.nl (8.9.3/8.9.3) with ESMTP id PAA10778 for ; Tue, 4 Sep 2001 15:53:15 +0200 (CEST) Message-Id: <4.3.2.7.2.20010904155327.035d2a00@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Sep 2001 15:53:33 +0200 To: linux XFS Mailing List From: Seth Mos Subject: Fwd: Re: TAKE - mount msgs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >X-XS4ALL-To: >X-Sender: blizbor@mail.ima.pl >X-Mailer: QUALCOMM Windows Eudora Version 5.1 >Date: Tue, 04 Sep 2001 15:50:10 +0200 >To: Seth Mos >From: Blizbor >Subject: Re: TAKE - mount msgs > >At 9/4/01 03:23 PM, you wrote: >One line is enough. What I don't know is if you could stick these messages >on one line. So the first mounting message without a \n and the succes or >fail message after it. > > >Don't know if it lets us do that. > >Sep 5 08:52:20 blizbor kernel: Start mounting filesystem: ide0(3,5) >Sep 5 08:55:38 blizbor kernel: Ending clean XFS mount for filesystem: >ide0(3,5) > >hmm ... what you can tell about such a system ? :>>> >Two lines are giving you two timestamps. It gives you chance >to a) measure performance of bad mounts, b) detect any problems. > >Really, I can't find any reason for cutting these lines out. >When you have one, central logs collecting server you have >no reason to login and check if filesystems are mounted. > >I don't know how to translate polish idiom "bicie piany" >but this thread is a big waste of time. >Please leave these lines. Everyone who doesnt like it can >remove them manually when compiling kernel. What a problem ? > >Regards, >Blizbor > >-- > > -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Sep 4 06:56:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84DuBf21277 for linux-xfs-outgoing; Tue, 4 Sep 2001 06:56:11 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84Du8d21257 for ; Tue, 4 Sep 2001 06:56:08 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 217731E135; Tue, 4 Sep 2001 15:56:03 +0200 (MEST) Date: Tue, 4 Sep 2001 15:55:55 +0200 From: Andi Kleen To: Ethan Benson Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - mount msgs Message-ID: <20010904155555.A30796@gruyere.muc.suse.de> References: <200109041139.VAA08035@snort.melbourne.sgi.com> <20010904134437.A28205@gruyere.muc.suse.de> <20010904225323.A344731@wobbly.melbourne.sgi.com> <20010904144323.B29262@gruyere.muc.suse.de> <20010904052113.X14519@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010904052113.X14519@plato.local.lan>; from erbenson@alaska.net on Tue, Sep 04, 2001 at 05:21:13AM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Sep 04, 2001 at 05:21:13AM -0800, Ethan Benson wrote: > On Tue, Sep 04, 2001 at 02:43:23PM +0200, Andi Kleen wrote: > > > Keeping the initial message only would be fine for me. > > why? at least on debian mount is called with -v which prints its own > (more informative) mounting message Doesn't help for the root fs. -Andi From owner-linux-xfs@oss.sgi.com Tue Sep 4 07:01:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84E1bO21521 for linux-xfs-outgoing; Tue, 4 Sep 2001 07:01:37 -0700 Received: from alaska.net (kitsune.nwc.alaska.net [209.112.130.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84E1Xd21502 for ; Tue, 4 Sep 2001 07:01:33 -0700 Received: from erbenson.alaska.net (75-pm18.nwc.alaska.net [209.112.142.75]) by alaska.net (8.9.1/8.9.1) with ESMTP id GAA29336 for ; Tue, 4 Sep 2001 06:01:32 -0800 (AKDT) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 4D676397B for ; Tue, 4 Sep 2001 06:01:29 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 6C8AF10246; Tue, 4 Sep 2001 06:01:29 -0800 (AKDT) Date: Tue, 4 Sep 2001 06:01:29 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: TAKE - mount msgs Message-ID: <20010904060129.A14519@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200109041139.VAA08035@snort.melbourne.sgi.com> <20010904134437.A28205@gruyere.muc.suse.de> <20010904225323.A344731@wobbly.melbourne.sgi.com> <20010904144323.B29262@gruyere.muc.suse.de> <20010904052113.X14519@plato.local.lan> <20010904155555.A30796@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XeHo0rFSNt4mQX/E" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010904155555.A30796@gruyere.muc.suse.de>; from ak@suse.de on Tue, Sep 04, 2001 at 03:55:55PM +0200 X-OS: Debian GNU Mail-Copies-To: nobody Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --XeHo0rFSNt4mQX/E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 04, 2001 at 03:55:55PM +0200, Andi Kleen wrote: > On Tue, Sep 04, 2001 at 05:21:13AM -0800, Ethan Benson wrote: > > On Tue, Sep 04, 2001 at 02:43:23PM +0200, Andi Kleen wrote: > >=20 > > > Keeping the initial message only would be fine for me. > >=20 > > why? at least on debian mount is called with -v which prints its own > > (more informative) mounting message >=20 > Doesn't help for the root fs. um... if the root filesystem doesn't mount i think your going to notice ;-) --=20 Ethan Benson http://www.alaska.net/~erbenson/ --XeHo0rFSNt4mQX/E Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuU3rkACgkQJKx7GixEevzN4wCgn9ZivLYBlRWegur5tb43n6zf uAMAnAtCvRbAdPGsmN07G0il2CGFXKPI =7IMG -----END PGP SIGNATURE----- --XeHo0rFSNt4mQX/E-- From owner-linux-xfs@oss.sgi.com Tue Sep 4 07:23:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84ENQZ22128 for linux-xfs-outgoing; Tue, 4 Sep 2001 07:23:26 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84ENNd22107 for ; Tue, 4 Sep 2001 07:23:23 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 148821E140; Tue, 4 Sep 2001 16:23:18 +0200 (MEST) Date: Tue, 4 Sep 2001 16:23:02 +0200 From: Andi Kleen To: Ethan Benson Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - mount msgs Message-ID: <20010904162302.A31393@gruyere.muc.suse.de> References: <200109041139.VAA08035@snort.melbourne.sgi.com> <20010904134437.A28205@gruyere.muc.suse.de> <20010904225323.A344731@wobbly.melbourne.sgi.com> <20010904144323.B29262@gruyere.muc.suse.de> <20010904052113.X14519@plato.local.lan> <20010904155555.A30796@gruyere.muc.suse.de> <20010904060129.A14519@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010904060129.A14519@plato.local.lan>; from erbenson@alaska.net on Tue, Sep 04, 2001 at 06:01:29AM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Sep 04, 2001 at 06:01:29AM -0800, Ethan Benson wrote: > On Tue, Sep 04, 2001 at 03:55:55PM +0200, Andi Kleen wrote: > > On Tue, Sep 04, 2001 at 05:21:13AM -0800, Ethan Benson wrote: > > > On Tue, Sep 04, 2001 at 02:43:23PM +0200, Andi Kleen wrote: > > > > > > > Keeping the initial message only would be fine for me. > > > > > > why? at least on debian mount is called with -v which prints its own > > > (more informative) mounting message > > > > Doesn't help for the root fs. > > um... if the root filesystem doesn't mount i think your going to > notice ;-) The point is that you can quickly blame XFS for it ("it crashed in XFS log replay"). With no message it is a lot harder to find which subsystem to debug. -Andi From owner-linux-xfs@oss.sgi.com Tue Sep 4 07:24:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84EO3f22267 for linux-xfs-outgoing; Tue, 4 Sep 2001 07:24:03 -0700 Received: from cwpads02.ud.com ([207.8.4.212]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84EO1d22248 for ; Tue, 4 Sep 2001 07:24:01 -0700 content-class: urn:content-classes:message Subject: root mount mislabled.. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 4 Sep 2001 09:24:00 -0500 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: root mount mislabled.. Thread-Index: AcE1TT28Xz+54kXVT+a9RB31pIN72g== From: "Joseph Southwell" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f84EO1d22249 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I am trying to use xfs as my root partition and it is being mislabeled. for instance I installed on /dev/hda3. I setup a smaller partition on dev/hda1 with xfs and booted to that partition. The data and the size of the root partition indicate that /dev/hda1 is mounted as root. however df indicates that /dev/hda3 is mounted as root. Because of this /dev/hda3 is transparent, in other words I can't mount it. This is the second time I have gone through this last time hda3 and hda1 were in opposite corners. I tried deleting the ext2 (at the time /dev/hda1) partition and then I got a bunch of read only filesystem errors during boot to the xfs partition. So this time I removed the read-only from the xfs boot partitions boot clause. It still mislabels them and I am reluctant to take risk destroying my system as it is used for other things and I already had to reinstall it once over this. So, short of trying to delete the existing ext2 partition any ideas on how to get the operating system to see this correctly? Joseph Southwell Solutions Engineer United Devices 512-692-4146 From owner-linux-xfs@oss.sgi.com Tue Sep 4 07:39:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84EdVd22751 for linux-xfs-outgoing; Tue, 4 Sep 2001 07:39:31 -0700 Received: from alaska.net (kitsune.nwc.alaska.net [209.112.130.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84EdRd22732 for ; Tue, 4 Sep 2001 07:39:27 -0700 Received: from erbenson.alaska.net (75-pm18.nwc.alaska.net [209.112.142.75]) by alaska.net (8.9.1/8.9.1) with ESMTP id GAA07575 for ; Tue, 4 Sep 2001 06:39:25 -0800 (AKDT) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 33A343924 for ; Tue, 4 Sep 2001 06:39:23 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 1399710246; Tue, 4 Sep 2001 06:39:22 -0800 (AKDT) Date: Tue, 4 Sep 2001 06:39:22 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: TAKE - mount msgs Message-ID: <20010904063922.C14519@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200109041139.VAA08035@snort.melbourne.sgi.com> <20010904134437.A28205@gruyere.muc.suse.de> <20010904225323.A344731@wobbly.melbourne.sgi.com> <20010904144323.B29262@gruyere.muc.suse.de> <20010904052113.X14519@plato.local.lan> <20010904155555.A30796@gruyere.muc.suse.de> <20010904060129.A14519@plato.local.lan> <20010904162302.A31393@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="o5hfEDzsoqw8wJwC" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010904162302.A31393@gruyere.muc.suse.de>; from ak@suse.de on Tue, Sep 04, 2001 at 04:23:02PM +0200 X-OS: Debian GNU Mail-Copies-To: nobody Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --o5hfEDzsoqw8wJwC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 04, 2001 at 04:23:02PM +0200, Andi Kleen wrote: >=20 > The point is that you can quickly blame XFS for it ("it crashed in XFS log > replay"). With no message it is a lot harder to find which subsystem to= =20 > debug. so print the messages in debug mode, but not otherwise. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --o5hfEDzsoqw8wJwC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuU55oACgkQJKx7GixEevwsqwCdFHirrNenCoVt1rvXyZFN17io EwYAoInxIGOuurHzhmQxhEkfuneWeD5o =JX3A -----END PGP SIGNATURE----- --o5hfEDzsoqw8wJwC-- From owner-linux-xfs@oss.sgi.com Tue Sep 4 08:35:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84FZTA24347 for linux-xfs-outgoing; Tue, 4 Sep 2001 08:35:29 -0700 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84FZPd24326 for ; Tue, 4 Sep 2001 08:35:26 -0700 Received: (from hch@localhost) by ns.caldera.de (8.11.1/8.11.1) id f84FZD330808; Tue, 4 Sep 2001 17:35:13 +0200 Date: Tue, 4 Sep 2001 17:35:12 +0200 From: Christoph Hellwig To: Simon Matter Cc: Ethan Benson , linux-xfs@oss.sgi.com Subject: Re: kernel spam when mounting xfs Message-ID: <20010904173512.A30319@caldera.de> References: <20010903194537.G14519@plato.local.lan> <3B947A63.F08A1245@ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B947A63.F08A1245@ch.sauter-bc.com>; from simon.matter@ch.sauter-bc.com on Tue, Sep 04, 2001 at 08:53:23AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Sep 04, 2001 at 08:53:23AM +0200, Simon Matter wrote: > Is this spam? Did you ever use ReiserFS? At least the sponsorship crap is ripped out in the kernel versions. There are more than enough (technical) reasons not to use reiserfs, though.. Christoph -- Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Tue Sep 4 08:38:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84Fcjd24555 for linux-xfs-outgoing; Tue, 4 Sep 2001 08:38:45 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84Fcbd24535; Tue, 4 Sep 2001 08:38:37 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 8FF4E6703F; Tue, 4 Sep 2001 17:38:30 +0200 (CEST) To: AKH Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com Subject: Re: about to try RAID.... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Tue, 4 Sep 2001 17:38:30 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 04.09.2001 17:38:41, Serialize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 04.09.2001 17:38:41, Serialize complete at 04.09.2001 17:38:41, Itemize by Notes Client on Michael Wahlbrink/ITS/Propack Data GmbH(Release 5.0.7 |March 21, 2001) at 04.09.2001 17:38:41, S/MIME Sign complete at 04.09.2001 17:38:41, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 04.09.2001 17:38:30, Serialize complete at 04.09.2001 17:38:30 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z14971_boundary_sign Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an S/MIME signed message. ---------z14971_boundary_sign Content-Type: text/plain; charset="us-ascii" On 04.09.2001 14:46:25 AKH wrote: >If you think getting 3ware controllers are hard in the UK - try getting >them >in Australia. The only way I got mine was to get it at the Asian >distributor >in Singapore when I was there on business. > >I'm in the process of doing exactly the same thing as you. At the >moment at >work I have 2 server machines running stress/benchmark tests - mongo.pl how do you get mongo.pl working with xfs? >& >bonie++. The tests have only been running for a day but so far the >3ware >controller has died on all 3 attempts at mongo.pl (but passes bonnie++), >whereas the machine running the 2 Promise TX2 controllers has not >missed a >beat. I still have quite a few more tests before I put either of them >into >service but so far it looks good for the Promise controllers. > cu micha ---------z14971_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggM/MIICJ6ADAgECAgQ7lLsBMA0GCSqGSIb3DQEBBAUAMIGcMQswCQYDVQQG EwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJs c3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBHbWJIMR4wHAYDVQQLExVDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkxIDAeBgNVBAMTF1Byb3BhY2sgRGF0YSBDbGFzcyAx IENBMB4XDTAxMDkwMzAwMDAwMFoXDTAyMDYxODIzNTkwMFowgakxCzAJBgNVBAYT AkRFMRswGQYDVQQIExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxz cnVoZTEaMBgGA1UEChMRUHJvcGFjayBEYXRhIEdtYkgxDDAKBgNVBAsTA0lUUzEa MBgGA1UEAxMRTWljaGFlbCBXYWhsYnJpbmsxIzAhBgkqhkiG9w0BCQEWFG1pd0Bw cm9wYWNrLWRhdGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRl70z rpIxvQtPawUDEEnQAEzkk8bad/BK6SQf1H5T8yujxbJb/f8edTx4rnAWE2r0RsNy NpQAdgAOBkJ2P599bb+iuGXDxncqQUx47AzLj7RV6Kph8iVWOFb+5yuLDsPcU03w T7eAHWU9qWj9NOR/vNT3Rt7vff85eNwFLWetNQIDAQABMA0GCSqGSIb3DQEBBAUA A4IBAQBUgk869M22A4nFoZ2FP4VktmkMH8FddO5pjdjQuRl1gGQb/ds4dsz82Q2f B9YRqFlQg1kZ6nEExxONyL7UUqbTJm/s17KONrae6jxktm2N55r7CRGbhRCJMLFE II3sa3Ttn1rK1UU/Cg0SVIcdQPVHcVTZwH93Zib/wQdaztfLJEa/6TUR/HU7Gc6z n9t4wDZaAWOEHnHtDfHLfH9COJxqljtBd8vJb8oQGu2mQ3YzvT292AQ6YjF4GAt/ cXFteP/zqjqLT0w81p/oOdyBhJZ+YGRavEpy8fKszzKU/AExqa4LKYJGDnATGVCO qtHOFs6eICDSu6ZpfDI5c/EhNxMOMIIDtjCCAp6gAwIBAgIEOU3ehzANBgkqhkiG 9w0BAQQFADCBnDELMAkGA1UEBhMCZGUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVt YmVyZzESMBAGA1UEBxMJS2FybHNydWhlMRowGAYDVQQKExFQcm9wYWNrIERhdGEg R21iSDEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSAwHgYDVQQDExdQ cm9wYWNrIERhdGEgQ2xhc3MgMSBDQTAeFw0wMDA2MTgwMDAwMDBaFw0wMjA2MTgy MzU5MDBaMIGcMQswCQYDVQQGEwJkZTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1i ZXJnMRIwEAYDVQQHEwlLYXJsc3J1aGUxGjAYBgNVBAoTEVByb3BhY2sgRGF0YSBH bWJIMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxIDAeBgNVBAMTF1By b3BhY2sgRGF0YSBDbGFzcyAxIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEApHbliMdXSZ4eYlfV+EE7A0e1htSUHt+wLFfFUXAoYA7Bp1A6FkYLI1Vl JBNE4fpXYtrFg9CP3LPrB1aXCxX2YYWza2joyW1DOvkPoE9uTSvyYbXMkENtz/5L Csn5xeJAihd6BoTSzWPUJnzbWSEuuV7O+6fP88E6Y01hVbEUCD9W6GeB3kCJbVD4 FP42ZicaksYLp7IctzoaDzHWRXL5oiqtPT6ujwMCrICNRnh4/qOe+tDHAdwI1+xq eDRjyp97gEG7XmkRs/JwSU5ABM1EQ6kAdNItVmO1w79UKL3KvcRreQiXSMKPCRVX VLAtntixr828a3s2uHW6HZ3Tq7Xb3QIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQB2 L3hFYcBp8Q+m5K1YtuEsDCQ6t3SZtu0nx+Wh2jXGYO1h23ABIWa60HK7tEVD5VdZ kdEZM1k84nHF9IS2vsf1JwQqY8dnUrDkVIGZcas3DxClqvx5iH2QMT8+lqSY9Kgq CtitD8ATsVncTm7QuC/9MPQybHPR1nDG3kqn4MGnmFIIEj+oDen1w8F9usqvK+1Q V/5WYmBBkEiOHhJsxovK6z6zzKFca9qF0/FO2WnvwGDdDgfQAdqz300C1vxHnmLW N8tWvkW63wRXuQrngc69m4dgAgwQR0Uh8aEh///0bkxFi6CvJD0k/p+sPOSATIB2 cIm/tERxeKmxPqAQuTKXAAAxgDCCAfYCAQEwgaUwgZwxCzAJBgNVBAYTAmRlMRsw GQYDVQQIExJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEa MBgGA1UEChMRUHJvcGFjayBEYXRhIEdtYkgxHjAcBgNVBAsTFUNlcnRpZmljYXRl IEF1dGhvcml0eTEgMB4GA1UEAxMXUHJvcGFjayBEYXRhIENsYXNzIDEgQ0ECBDuU uwEwCQYFKw4DAhoFAKCBqzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MDQxNTM4NDFaMCMGCSqGSIb3DQEJBDEWBBQjmtiGSlsT 9LsfoyIyB06y/r3ssTBMBgkqhkiG9w0BCQ8xPzA9MAcGBSsOAwIdMA4GCCqGSIb3 DQMCAgIAgDAKBggqhkiG9w0DBzAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkq hkiG9w0BAQEFAASBgMa8DnXtWtHOt0D4c5aHcld9Y0ioAwtbRVWjkdPiscGhxhwv 5jr2LX6BCA2NFMQ0L1SxuSlcQIY4KXT++ejPRyYNK4B7NcNM3ECluAkUJHCVbf1j 7KCJyvWJj/QckOJ5PGAG3Cf2ihzjvR8ZFfJ7a7jn6+Sk+HmXPKFFooQL6TRlAAAA AAAAAAA= ---------z14971_boundary_sign-- From owner-linux-xfs@oss.sgi.com Tue Sep 4 08:39:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84Fdo124714 for linux-xfs-outgoing; Tue, 4 Sep 2001 08:39:50 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84Fdld24671 for ; Tue, 4 Sep 2001 08:39:47 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA09266 for ; Tue, 4 Sep 2001 08:38:10 -0700 (PDT) mail_from (nstraz@sgi.com) Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA54315; Tue, 4 Sep 2001 10:38:29 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.32 #1 (Debian)) id 15eIHV-0000RR-00; Tue, 04 Sep 2001 10:38:29 -0500 Date: Tue, 4 Sep 2001 10:38:29 -0500 From: Nathan Straz To: Joseph Southwell Cc: linux-xfs@oss.sgi.com Subject: Re: root mount mislabled.. Message-ID: <20010904103828.A726@sgi.com> Mail-Followup-To: Joseph Southwell , linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Sep 04, 2001 at 09:24:00AM -0500, Joseph Southwell wrote: > I am trying to use xfs as my root partition and it is being > mislabeled. for instance I installed on /dev/hda3. I setup a smaller > partition on dev/hda1 with xfs and booted to that partition. The data > and the size of the root partition indicate that /dev/hda1 is mounted as > root. however df indicates that /dev/hda3 is mounted as root. There are two mounted partitions tables, /etc/mtab and /proc/mounts. /proc/mounts is what the kernel uses and is always correct. /etc/mtab is the user space table and can be wrong. This usually happens if you pass a "root=" option to the kernel that differs from what's in /etc/fstab. If /proc/mounts has /dev/root use /usr/sbin/rdev to find out what your real root partition is. Sometimes is do a `cat /proc/mounts > /etc/mtab` if the differences get in my way, but I don't know how safe that is. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Tue Sep 4 08:39:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84FdqZ24734 for linux-xfs-outgoing; Tue, 4 Sep 2001 08:39:52 -0700 Received: from mailfast.internal.ima.pl (ip222ds.ima.pl [62.89.65.222]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84Fdhd24668 for ; Tue, 4 Sep 2001 08:39:44 -0700 Received: from mailhub.internal.ima.pl by mailfast.internal.ima.pl with ESMTP id f84FdUh12914 for ; Tue, 4 Sep 2001 17:39:30 +0200 Received: from mail.ima.pl by mailhub.internal.ima.pl with ESMTP id f84FdTR12909 for ; Tue, 4 Sep 2001 17:39:29 +0200 Received: from blizbor.ima.pl (jurek.primark.gdansk.tpnet.pl [195.117.150.37]) by mail.ima.pl with ESMTP id f84FdTV00685 for ; Tue, 4 Sep 2001 17:39:29 +0200 Message-Id: <5.1.0.14.0.20010904173732.01f17cc0@mail.ima.pl> X-Sender: blizbor@mail.ima.pl X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 17:43:57 +0200 To: linux-xfs@oss.sgi.com From: Blizbor Subject: Re: TAKE - mount msgs In-Reply-To: <20010904063922.C14519@plato.local.lan> References: <20010904162302.A31393@gruyere.muc.suse.de> <200109041139.VAA08035@snort.melbourne.sgi.com> <20010904134437.A28205@gruyere.muc.suse.de> <20010904225323.A344731@wobbly.melbourne.sgi.com> <20010904144323.B29262@gruyere.muc.suse.de> <20010904052113.X14519@plato.local.lan> <20010904155555.A30796@gruyere.muc.suse.de> <20010904060129.A14519@plato.local.lan> <20010904162302.A31393@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 9/4/01 04:39 PM, Ethan Benson wrote: >On Tue, Sep 04, 2001 at 04:23:02PM +0200, Andi Kleen wrote: >> >> The point is that you can quickly blame XFS for it ("it crashed in XFS log >> replay"). With no message it is a lot harder to find which subsystem to >> debug. > >so print the messages in debug mode, but not otherwise. Ethan, so what next ? pppd authors ? ethernet drivers authors ? maybe guys doing scsi ? What should be changed next to produce less initial output ? Please, don't be silly. When you are managing network you NEED those messages. Two lines less or more when you are taking megabytes of logs daily really doesn't matter. There are grep, sed or so other more or less advanced tools to cut something from logs, but none of them could add something in the case of problems. If they are not necessary for you, remove them itself for your own usage. It's the OpenSource power - change to feet your needs. Regards, Blizbor From owner-linux-xfs@oss.sgi.com Tue Sep 4 08:42:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84Fgsf25027 for linux-xfs-outgoing; Tue, 4 Sep 2001 08:42:54 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84Fgqd25008 for ; Tue, 4 Sep 2001 08:42:52 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f84Fgk515792 for ; Tue, 4 Sep 2001 08:42:46 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2884109; Tue, 4 Sep 2001 10:41:31 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA92168; Tue, 4 Sep 2001 10:41:30 -0500 (CDT) Message-ID: <3B94F5D7.C4E4CD75@sgi.com> Date: Tue, 04 Sep 2001 10:40:07 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: monkeyiq CC: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: Preallocation of space References: <200109030908.f83988S26342@monkeyiq.dnsalias.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk monkeyiq wrote: > I've found this page which I'll use as my reference to syssgi() > unless there is a better online version. > http://reality.sgi.com/cgi-bin/getman?syssgi-2#toc1 If you want to use it as a reference, save it locally... reality *might* going away... :( -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 4 08:44:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84FiDf25170 for linux-xfs-outgoing; Tue, 4 Sep 2001 08:44:13 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84Fi9d25151 for ; Tue, 4 Sep 2001 08:44:09 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id RAA10170; Tue, 4 Sep 2001 17:44:07 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id RAA12071; Tue, 4 Sep 2001 17:44:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 82B6057306; Tue, 4 Sep 2001 17:43:42 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 4183A25835; Tue, 4 Sep 2001 17:43:42 +0200 (CEST) Message-ID: <3B94F6AE.F516522@ch.sauter-bc.com> Date: Tue, 04 Sep 2001 17:43:42 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Andi Kleen Cc: Ethan Benson , linux-xfs@oss.sgi.com Subject: Re: TAKE - mount msgs References: <200109041139.VAA08035@snort.melbourne.sgi.com> <20010904134437.A28205@gruyere.muc.suse.de> <20010904225323.A344731@wobbly.melbourne.sgi.com> <20010904144323.B29262@gruyere.muc.suse.de> <20010904052113.X14519@plato.local.lan> <20010904155555.A30796@gruyere.muc.suse.de> <20010904060129.A14519@plato.local.lan> <20010904162302.A31393@gruyere.muc.suse.de> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andi Kleen schrieb: > > On Tue, Sep 04, 2001 at 06:01:29AM -0800, Ethan Benson wrote: > > On Tue, Sep 04, 2001 at 03:55:55PM +0200, Andi Kleen wrote: > > > On Tue, Sep 04, 2001 at 05:21:13AM -0800, Ethan Benson wrote: > > > > On Tue, Sep 04, 2001 at 02:43:23PM +0200, Andi Kleen wrote: > > > > > > > > > Keeping the initial message only would be fine for me. > > > > > > > > why? at least on debian mount is called with -v which prints its own > > > > (more informative) mounting message > > > > > > Doesn't help for the root fs. > > > > um... if the root filesystem doesn't mount i think your going to > > notice ;-) > > The point is that you can quickly blame XFS for it ("it crashed in XFS log > replay"). With no message it is a lot harder to find which subsystem to > debug. I agree with this. Anyway it's a really good sign for XFS. If we don't have more important stuff to discuss here it means that XFS is _really_ good. I know it is very good but... -Simon From owner-linux-xfs@oss.sgi.com Tue Sep 4 08:48:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84FmUk25424 for linux-xfs-outgoing; Tue, 4 Sep 2001 08:48:30 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84FmRd25403 for ; Tue, 4 Sep 2001 08:48:27 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f84FmLJ08531 for ; Tue, 4 Sep 2001 08:48:21 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2885324; Tue, 4 Sep 2001 10:47:06 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA03924; Tue, 4 Sep 2001 10:47:05 -0500 (CDT) Message-ID: <3B94F726.E978C299@sgi.com> Date: Tue, 04 Sep 2001 10:45:42 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Gonyou, Austin" CC: "'Seth Mos'" , XFS mailing list Subject: Re: System lock while accessing files causes file corruption References: <85063BBE668FD411944400D0B744267A888526@AUSMAIL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Gonyou, Austin" wrote: > > That's all well and good..but what about the configuration files? They are > text and are not redundant in the same way. In my spare time (!) I'm working on characterizing how long it takes a write to get out to disk on average, it seem to be on the order of 30 seconds, with normal mount options (this should be ~ the same as with ext2, for example). This is what I would expect based on bdflush, etc, but some people's experience suggests that it's taking longer, this is really something I want to feel sure of. But in any case, it occurred to me that you could make /etc on it's own partition, and mount that O_SYNC - I don't think that would be too much overhead, /etc doesn't get written that much on a normal system (?). If Oracle puts config files elsewhere, you could simlink them onto this filesystem. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 4 08:58:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84FwcW25783 for linux-xfs-outgoing; Tue, 4 Sep 2001 08:58:38 -0700 Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84Fwad25764 for ; Tue, 4 Sep 2001 08:58:36 -0700 Received: from heppcl.ph.qmw.ac.uk ([138.37.50.187]) by zeta.qmw.ac.uk with esmtp (Exim 3.16 #1) id 15eIaw-0000Mr-00; Tue, 04 Sep 2001 16:58:34 +0100 Received: from heppct.ph.qmw.ac.uk (heppct.ph.qmw.ac.uk [138.37.50.246]) by heppcl.ph.qmw.ac.uk (8.9.3/8.9.3) with ESMTP id QAA08704; Tue, 4 Sep 2001 16:58:34 +0100 Received: from localhost (pd@localhost) by heppct.ph.qmw.ac.uk (8.11.2/8.9.3) with ESMTP id f84FwYj27352; Tue, 4 Sep 2001 16:58:34 +0100 X-Authentication-Warning: heppct.ph.qmw.ac.uk: pd owned process doing -bs Date: Tue, 4 Sep 2001 16:58:34 +0100 (BST) From: "P.Dixon" To: Michael Wahlbrink cc: Subject: Re: about to try RAID.... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > If you think getting 3ware controllers are hard in the UK - try > getting them in Australia. The only way I got mine was to get it at > the Asian distributor in Singapore when I was there on business. > For anyone who's interested, I just ordered the 3Ware Escalade 6800 (8 port) card and 8 24" cables for the grand total of 400 UK pounds from TMC-UK - www.tmc-uk.com (sent them an email and got a reply back within minutes). This is approx $640(US) - if I bought from www.hypermicro.com, it would cost me just $309(US) or 193 UK pounds. Another example off Rip Off Britain. Right, I need to read up on LVM... Cheerio, Paul From owner-linux-xfs@oss.sgi.com Tue Sep 4 09:22:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84GMmh26348 for linux-xfs-outgoing; Tue, 4 Sep 2001 09:22:48 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84GMjd26329 for ; Tue, 4 Sep 2001 09:22:45 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA00204 for ; Tue, 4 Sep 2001 09:21:08 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA2634880; Tue, 4 Sep 2001 11:20:14 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA23283; Tue, 4 Sep 2001 11:20:12 -0500 (CDT) Message-ID: <3B94FEE8.F29DA88B@sgi.com> Date: Tue, 04 Sep 2001 11:18:48 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Schutte CC: Seth Mos , XFS mailing list Subject: Re: Kernel hangs with mongo.pl benchmark. References: <3B929996.FFC809B9@it.up.ac.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Paul Schutte wrote: > > > > > > > > Hi, > > > > > > > > I found a problem while doing benchmarks with mongo.pl > I Think this is a SCSI thing. > I just ran it on a BusLogic card. > I saw the same sympthoms: only bdflush running. Hm, apparently the "reserved buffer head pool" change I put in is possibly the culprit.... you guys could either try backing that out or wait for me to figure out what went wrong... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 4 09:33:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84GXgn26665 for linux-xfs-outgoing; Tue, 4 Sep 2001 09:33:42 -0700 Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84GXdd26612 for ; Tue, 4 Sep 2001 09:33:39 -0700 Received: from [195.20.224.208] (helo=mrvdom01.schlund.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 15eJ8r-00003M-00; Tue, 4 Sep 2001 18:33:37 +0200 Received: from pd901e253.dip.t-dialin.net ([217.1.226.83] helo=kernelpanix.aura.of.mankind) by mrvdom01.schlund.de with esmtp (Exim 2.12 #2) id 15eJ8r-0002m1-00; Tue, 4 Sep 2001 18:33:37 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id f84FvsN14161; Tue, 4 Sep 2001 17:57:54 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Tue, 4 Sep 2001 17:57:54 +0200 From: utz lehmann To: Eric Sandeen Cc: "Gonyou, Austin" , "'Seth Mos'" , XFS mailing list Subject: Re: System lock while accessing files causes file corruption Message-ID: <20010904175754.A14064@s2y4n2c.de> References: <85063BBE668FD411944400D0B744267A888526@AUSMAIL> <3B94F726.E978C299@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B94F726.E978C299@sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric Eric Sandeen [sandeen@sgi.com] wrote: > But in any case, it occurred to me that you could make /etc on it's own > partition, and mount that O_SYNC - I don't think that would be too much > overhead, /etc doesn't get written that much on a normal system (?). If > Oracle puts config files elsewhere, you could simlink them onto this > filesystem. You can't make /etc on a different partition than /. /etc, /sbin, /dev (without devfs) must on the / partition otherwise your system will not boot. utz From owner-linux-xfs@oss.sgi.com Tue Sep 4 09:33:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84GXdh26601 for linux-xfs-outgoing; Tue, 4 Sep 2001 09:33:39 -0700 Received: from cwpads02.ud.com ([207.8.4.212]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84GXZd26581 for ; Tue, 4 Sep 2001 09:33:35 -0700 content-class: urn:content-classes:message Subject: RE: root mount mislabled.. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 4 Sep 2001 11:33:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: root mount mislabled.. Thread-Index: AcE1XbgTt0SMQRyWThO9J3pvJQaYXwAARYkA From: "Joseph Southwell" To: "Nathan Straz" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f84GXad26582 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk mtab is being populated by calling mount -f. Root is set to LABEL=/ in /etc/fstab, if I change it to /dev/hda1 I get stopped during boot up because fsck tries to run and determines that the partition isn't ext2. I went into the single user shell it gave me there and df/mount are still disagreeing with rdev so that broke something and didn't solve the problem. Any other ideas? -----Original Message----- From: Nathan Straz [mailto:nstraz@sgi.com] Sent: Tuesday, September 04, 2001 11:22 AM To: Joseph Southwell Subject: Re: root mount mislabled.. On Tue, Sep 04, 2001 at 11:09:07AM -0500, Joseph Southwell wrote: > /proc/mounts says /dev/root > rdev says /dev/hda1. which is what I expected because I can tell that > one is mounted. > root=/dev/hda1 in the lilo.conf file for this boot image. > I tried correcting the mtab as you suggested, that change does not > survive a boot. Any other thoughts? Update your /etc/fstab to use /dev/hda1 as your root since that's what you're doing anyway. I think most of the rc.sysinit scripts I've seen rewrite /etc/mtab using /etc/fstab during boot. It has to do with mount wanting to update /etc/mtab while / is still read-only, so rc.sysinit fakes it after / is mounted read-write. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Tue Sep 4 09:37:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84Gb2G26882 for linux-xfs-outgoing; Tue, 4 Sep 2001 09:37:02 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84Gb0d26863 for ; Tue, 4 Sep 2001 09:37:00 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA09394 for ; Tue, 4 Sep 2001 09:35:23 -0700 (PDT) mail_from (nstraz@sgi.com) Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA57267; Tue, 4 Sep 2001 11:35:42 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.32 #1 (Debian)) id 15eJAs-0000Zf-00; Tue, 04 Sep 2001 11:35:42 -0500 Date: Tue, 4 Sep 2001 11:35:42 -0500 From: Nathan Straz To: Joseph Southwell Cc: linux-xfs@oss.sgi.com Subject: Re: root mount mislabled.. Message-ID: <20010904113541.C726@sgi.com> Mail-Followup-To: Joseph Southwell , linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Sep 04, 2001 at 11:33:35AM -0500, Joseph Southwell wrote: > mtab is being populated by calling mount -f. Root is set to LABEL=/ in > /etc/fstab, if I change it to /dev/hda1 I get stopped during boot up > because fsck tries to run and determines that the partition isn't ext2. > I went into the single user shell it gave me there and df/mount are > still disagreeing with rdev so that broke something and didn't solve the > problem. Any other ideas? Did you change the file system type in /etc/fstab? Maybe we need to see a copy of your /etc/fstab, just two double check. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Tue Sep 4 09:41:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84Gfr427070 for linux-xfs-outgoing; Tue, 4 Sep 2001 09:41:53 -0700 Received: from cwpads02.ud.com ([207.8.4.212]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84Gfod27050 for ; Tue, 4 Sep 2001 09:41:50 -0700 content-class: urn:content-classes:message Subject: RE: root mount mislabled.. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 4 Sep 2001 11:41:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: root mount mislabled.. Thread-Index: AcE1X6UYyut/Ldu/QkqAXyoWb3acLwAAMBxw From: "Joseph Southwell" To: "Nathan Straz" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f84Gfpd27051 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The filesystem type was the problem. Thank for your patience. -----Original Message----- From: Nathan Straz [mailto:nstraz@sgi.com] Sent: Tuesday, September 04, 2001 11:36 AM To: Joseph Southwell Cc: linux-xfs@oss.sgi.com Subject: Re: root mount mislabled.. On Tue, Sep 04, 2001 at 11:33:35AM -0500, Joseph Southwell wrote: > mtab is being populated by calling mount -f. Root is set to LABEL=/ in > /etc/fstab, if I change it to /dev/hda1 I get stopped during boot up > because fsck tries to run and determines that the partition isn't ext2. > I went into the single user shell it gave me there and df/mount are > still disagreeing with rdev so that broke something and didn't solve the > problem. Any other ideas? Did you change the file system type in /etc/fstab? Maybe we need to see a copy of your /etc/fstab, just two double check. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Tue Sep 4 10:34:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84HYBt28053 for linux-xfs-outgoing; Tue, 4 Sep 2001 10:34:11 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84HY7d28034 for ; Tue, 4 Sep 2001 10:34:07 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id TAA20627; Tue, 4 Sep 2001 19:33:32 +0200 (CEST) Message-Id: <4.3.2.7.2.20010904193203.032499a0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Sep 2001 19:33:49 +0200 To: utz lehmann , Eric Sandeen From: Seth Mos Subject: Re: System lock while accessing files causes file corruption Cc: "Gonyou, Austin" , XFS mailing list In-Reply-To: <20010904175754.A14064@s2y4n2c.de> References: <3B94F726.E978C299@sgi.com> <85063BBE668FD411944400D0B744267A888526@AUSMAIL> <3B94F726.E978C299@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 17:57 4-9-2001 +0200, utz lehmann wrote: >Hi Eric > >Eric Sandeen [sandeen@sgi.com] wrote: > > But in any case, it occurred to me that you could make /etc on it's own > > partition, and mount that O_SYNC - I don't think that would be too much > > overhead, /etc doesn't get written that much on a normal system (?). If > > Oracle puts config files elsewhere, you could simlink them onto this > > filesystem. > >You can't make /etc on a different partition than /. >/etc, /sbin, /dev (without devfs) must on the / partition otherwise your >system will not boot. If you use a decent layout fopr your data it does not matter. If you have a separate /usr /var /tmp /home like most servers do you could just mount your / fs O_SYNC since it would only have a _very_ slight performance loss since you almost never write to the root fs. :-) Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Sep 4 10:53:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84HrXo28606 for linux-xfs-outgoing; Tue, 4 Sep 2001 10:53:33 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84HrUd28587 for ; Tue, 4 Sep 2001 10:53:30 -0700 Received: from scare ([63.231.179.33]) by lips.borg.umn.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f84HrLXi091451; Tue, 4 Sep 2001 12:53:22 -0500 (CDT) Subject: Re: TAKE - mount msgs From: Russell Cattelan To: Andi Kleen Cc: Ethan Benson , linux-xfs@oss.sgi.com In-Reply-To: <20010904162302.A31393@gruyere.muc.suse.de> References: <200109041139.VAA08035@snort.melbourne.sgi.com> <20010904134437.A28205@gruyere.muc.suse.de> <20010904225323.A344731@wobbly.melbourne.sgi.com> <20010904144323.B29262@gruyere.muc.suse.de> <20010904052113.X14519@plato.local.lan> <20010904155555.A30796@gruyere.muc.suse.de> <20010904060129.A14519@plato.local.lan> <20010904162302.A31393@gruyere.muc.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 04 Sep 2001 12:46:33 -0500 Message-Id: <999625595.30969.4.camel@scare> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 04 Sep 2001 16:23:02 +0200, Andi Kleen wrote: > On Tue, Sep 04, 2001 at 06:01:29AM -0800, Ethan Benson wrote: > > On Tue, Sep 04, 2001 at 03:55:55PM +0200, Andi Kleen wrote: > > > On Tue, Sep 04, 2001 at 05:21:13AM -0800, Ethan Benson wrote: > > > > On Tue, Sep 04, 2001 at 02:43:23PM +0200, Andi Kleen wrote: > > > > > > > > > Keeping the initial message only would be fine for me. > > > > > > > > why? at least on debian mount is called with -v which prints its own > > > > (more informative) mounting message > > > > > > Doesn't help for the root fs. > > > > um... if the root filesystem doesn't mount i think your going to > > notice ;-) > > The point is that you can quickly blame XFS for it ("it crashed in XFS log > replay"). With no message it is a lot harder to find which subsystem to > debug. Yes... I agree, having a the mount message is very helpful especially when loading xfs as a module... I vote for leaving the message in ... maybe shrink it to one line if people really thinks it's "cluttering" up the log to much. > > > -Andi From owner-linux-xfs@oss.sgi.com Tue Sep 4 10:56:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84Huwu28802 for linux-xfs-outgoing; Tue, 4 Sep 2001 10:56:58 -0700 Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84Husd28782 for ; Tue, 4 Sep 2001 10:56:54 -0700 Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 15eKRP-000Jl8-0W for linux-xfs@oss.sgi.com; Tue, 4 Sep 2001 18:56:51 +0100 Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3]) by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id 8E4D027EF for ; Tue, 4 Sep 2001 18:56:49 +0100 (BST) Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001) id BBF8B125E6; Tue, 4 Sep 2001 18:56:46 +0100 (BST) Date: Tue, 4 Sep 2001 18:56:46 +0100 (BST) From: Keith Matthews Subject: Re[2]: System lock while accessing files causes file corruption To: linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20010904193203.032499a0@pop.xs4all.nl> References: <3B94F726.E978C299@sgi.com> <85063BBE668FD411944400D0B744267A888526@AUSMAIL> <3B94F726.E978C299@sgi.com>, <4.3.2.7.2.20010904193203.032499a0@pop.xs4all.nl> X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Disposition: INLINE Message-Id: <20010904175646.BBF8B125E6@rebutia.sweeney.demon.co.uk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f84Hutd28783 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 04 Sep 2001 19:33:49 +0200 Seth Mos > wrote: > At 17:57 4-9-2001 +0200, utz lehmann wrote: > >Hi Eric > > > >Eric Sandeen [sandeen@sgi.com] wrote: > > > But in any case, it occurred to me that you could make /etc on it's own > > > partition, and mount that O_SYNC - I don't think that would be too much > > > overhead, /etc doesn't get written that much on a normal system (?). If > > > Oracle puts config files elsewhere, you could simlink them onto this > > > filesystem. > > > >You can't make /etc on a different partition than /. > >/etc, /sbin, /dev (without devfs) must on the / partition otherwise your > >system will not boot. > If you use a decent layout fopr your data it does not matter. > If you have a separate /usr /var /tmp /home like most servers do you could > just mount your / fs O_SYNC since it would only have a _very_ slight > performance loss since you almost never write to the root fs. :-) If you use Oracle's recommended layout you have (at least ) 4 top level mount points. It does not use OS config directories for its config for good reasons - you may want to have more than one database instance on a host. Well designed layouts for database files should have no problems with special control. Its better to have synced writes for the data files anyway as the DBMS does its own caching. -- Keith Matthews Spam trap - my real account at this node is keith_m Frequentous Consultants - Linux Services, Oracle development & database administration From owner-linux-xfs@oss.sgi.com Tue Sep 4 12:27:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84JRbs30434 for linux-xfs-outgoing; Tue, 4 Sep 2001 12:27:37 -0700 Received: from adriano.agestado.com.br (avantesma.oesp.com.br [200.196.192.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84JRQd30406 for ; Tue, 4 Sep 2001 12:27:27 -0700 Received: (qmail 1606 invoked by uid 666); 4 Sep 2001 19:27:14 -0000 Date: Tue, 4 Sep 2001 16:27:14 -0300 From: Adriano Nagelschmidt Rodrigues To: linux-xfs@oss.sgi.com Subject: Re: kernel spam when mounting xfs Message-ID: <20010904162714.A1567@agestado.com.br> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.20i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Christoph Hellwig writes: > At least the sponsorship crap is ripped out in the kernel versions. > There are more than enough (technical) reasons not to use reiserfs, > though.. Ok, I'll bite, I use ReiserFS and I'm new to this list. What are the technical reasons not to use ReiserFS? Thanks, -- Adriano From owner-linux-xfs@oss.sgi.com Tue Sep 4 13:41:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84KfJ232023 for linux-xfs-outgoing; Tue, 4 Sep 2001 13:41:19 -0700 Received: from imapserverb.fnal.gov (imapserverb.fnal.gov [131.225.9.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84KfDd32003 for ; Tue, 4 Sep 2001 13:41:14 -0700 Received: from imapserverb.fnal.gov ([131.225.9.17]) by imapserverb.fnal.gov (Netscape Messaging Server 4.15) with SMTP id GJ5O4O00.402 for ; Tue, 4 Sep 2001 15:41:12 -0500 Received: from fnal.gov ([131.225.7.82]) by imapserverb.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001090415411115294 ; Tue, 04 Sep 2001 15:41:11 -0500 Message-ID: <3B953C69.BBACF47@fnal.gov> Date: Tue, 04 Sep 2001 15:41:13 -0500 From: yocum@fnal.gov X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Federico Sevilla III CC: "Philippine Linux Users' Group Mailing List" , Linux XFS Mailing List Subject: Re: Playing around with NFS+XFS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jijo, Federico Sevilla III wrote: > Version 1.01d ------Sequential Output------ --Sequential Input---Rando > -Per Chr- --Block-- -Rewrite- -Per Chr- --Block----Seeks > Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec % > Gusi-NFS-XFS 1G 4200 82 5937 7 1988 4 4037 76 10512 9 120.3 >>-------------------------------^^^^ That's the best you'll get out of your 3ware 6400 card under RAID5, so your bottleneck is the card, not the network, here. :-( If you want good performance out of a 3ware card, use RAID 1 or 10 (if you have a 6x00 card) or get a 7x10, which will do about 17MB/s in RAID5. It's still not great, but a lot better than 6MB/s. RAID1/10 on the 7810 is >>100MB/s for writes, and about 180MB/s reads. So, here's what I get for performance on NFSv3 over gigabit ethernet to XFS (I didn't tweak the r/wmem_default values, only the r/wmem_max. r/wsize is set to 32k. Version 1.01c ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP dp9nfsdp8 2000M:64k 10918 96 25679 23 8436 14 10731 99 42655 34 100.8 5 dp9nfsdp8 2000M:64k 10992 98 25247 23 9225 15 10749 99 48310 44 121.7 6 dp9nfsdp8 2000M:64k 11022 98 24388 21 8503 14 10729 99 45993 39 113.1 6 dp9nfsdp8 2000M:64k 11027 98 25949 23 8467 15 10752 99 41494 32 101.4 6 dp9nfsdp8 2000M:64k 10968 98 26145 24 8760 15 10751 99 43958 36 98.0 6 dp9nfsdp8 2000M:64k 11037 98 28687 27 8533 15 10747 99 43546 36 101.7 6 dp9nfsdp8 2000M:64k 11053 98 24593 21 8513 14 10751 99 41769 33 102.2 5 The XFS volume is RAID50, hw RAID5, then sw RAID0 (striped), hence the reason I can get >17MB/s. I used a 512kb chunksize for the sw RAID0, but I think I might be able to get better performance if I used 448kb. *and* no data/inode corruption now that '-i size=512' now. Cheers, Dan -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Tue Sep 4 15:25:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84MP8X02075 for linux-xfs-outgoing; Tue, 4 Sep 2001 15:25:08 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84MP5d02052 for ; Tue, 4 Sep 2001 15:25:05 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f84MOr521866 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 4 Sep 2001 15:24:53 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id AAA912528 for ; Wed, 5 Sep 2001 00:24:56 +0200 (CEST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA02802; Wed, 5 Sep 2001 09:23:33 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA63859; Wed, 5 Sep 2001 09:23:21 +1100 (AEDT) Date: Wed, 5 Sep 2001 09:23:21 +1100 From: Nathan Scott To: Russell Cattelan Cc: Andi Kleen , Ethan Benson , linux-xfs@oss.sgi.com Subject: Re: TAKE - mount msgs Message-ID: <20010905092321.A324361@wobbly.melbourne.sgi.com> References: <200109041139.VAA08035@snort.melbourne.sgi.com> <20010904134437.A28205@gruyere.muc.suse.de> <20010904225323.A344731@wobbly.melbourne.sgi.com> <20010904144323.B29262@gruyere.muc.suse.de> <20010904052113.X14519@plato.local.lan> <20010904155555.A30796@gruyere.muc.suse.de> <20010904060129.A14519@plato.local.lan> <20010904162302.A31393@gruyere.muc.suse.de> <999625595.30969.4.camel@scare> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <999625595.30969.4.camel@scare>; from cattelan@thebarn.com on Tue, Sep 04, 2001 at 12:46:33PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Russell, On Tue, Sep 04, 2001 at 12:46:33PM -0500, Russell Cattelan wrote: > On 04 Sep 2001 16:23:02 +0200, Andi Kleen wrote: > > > > The point is that you can quickly blame XFS for it ("it crashed in XFS log > > replay"). With no message it is a lot harder to find which subsystem to > > debug. > Yes... I agree, having a the mount message is very helpful especially > when loading xfs as a module... > > I vote for leaving the message in ... maybe shrink it to one line if > people really thinks it's "cluttering" up the log to much. > Yup, thanks - thats what I ended up doing - leaving in just one line for the normal (clean log) case, more if anything unusual is happening, and more for debug kernels. And now back to doing some real work... cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Sep 4 15:24:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84MOAB02010 for linux-xfs-outgoing; Tue, 4 Sep 2001 15:24:10 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84MO8d01991 for ; Tue, 4 Sep 2001 15:24:08 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f84MO2521800 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 4 Sep 2001 15:24:02 -0700 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA911730 for ; Wed, 5 Sep 2001 00:24:06 +0200 (CEST) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA71446 for ; Tue, 4 Sep 2001 15:28:59 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id A51E915A213 for ; Tue, 4 Sep 2001 15:22:32 -0700 (PDT) Subject: Re: TAKE - mount msgs From: Florin Andrei To: linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20010904152044.035d3b48@pop.xs4all.nl> References: <20010904225323.A344731@wobbly.melbourne.sgi.com> <200109041139.VAA08035@snort.melbourne.sgi.com> <20010904134437.A28205@gruyere.muc.suse.de> <20010904225323.A344731@wobbly.melbourne.sgi.com> <4.3.2.7.2.20010904152044.035d3b48@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 04 Sep 2001 15:22:32 -0700 Message-Id: <999642152.29244.153.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 04 Sep 2001 15:23:12 +0200, Seth Mos wrote: > > I like having at least one message that it mounted a certain fs. I can then > use dmesg to see if it actually worked, and if it needs to recover or if it > fails I like to see it as well. One line per partition seems to be the best tradeoff: "filesystem /dev/blahblah failed" or "filesystem /dev/foobar succeeded" or something. And maybe just one more line when the module is loaded up (if XFS is a module). -- Florin Andrei "Our kernel does have source control: its name is Linus Torvalds, CVS with a brain." - Nicholas Knight From owner-linux-xfs@oss.sgi.com Tue Sep 4 15:28:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84MSR302349 for linux-xfs-outgoing; Tue, 4 Sep 2001 15:28:27 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84MSPd02329 for ; Tue, 4 Sep 2001 15:28:25 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id f84MSJ522094 for ; Tue, 4 Sep 2001 15:28:19 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA02823; Wed, 5 Sep 2001 09:27:02 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA33508; Wed, 5 Sep 2001 09:27:02 +1100 (AEDT) Date: Wed, 5 Sep 2001 09:27:01 +1100 From: Nathan Scott To: Joseph Southwell Cc: Nathan Straz , linux-xfs@oss.sgi.com Subject: Re: root mount mislabled.. Message-ID: <20010905092701.B324361@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from joseph@ud.com on Tue, Sep 04, 2001 at 11:33:35AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Tue, Sep 04, 2001 at 11:33:35AM -0500, Joseph Southwell wrote: > mtab is being populated by calling mount -f. Root is set to LABEL=/ in > /etc/fstab, if I change it to /dev/hda1 I get stopped during boot up > because fsck tries to run and determines that the partition isn't ext2. This particular problem, ie. the fsck frontend not understanding "LABEL=" and "UUID=" for XFS filesystems, has now been fixed in the current e2fsprogs release (http://e2fsprogs.sourceforge.net/) - version 1.24 is the first with the fix, I believe. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Sep 4 15:49:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84MnWi02816 for linux-xfs-outgoing; Tue, 4 Sep 2001 15:49:32 -0700 Received: from commsrvr.projectdesign.com ([63.98.246.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84MnSd02794 for ; Tue, 4 Sep 2001 15:49:29 -0700 Received: by commsrvr.projectdesign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Sep 2001 15:49:22 -0700 Message-ID: <58FE74F275AFD411900800508B556525943AD3@commsrvr.projectdesign.com> From: Joshua Penix To: linux-xfs@oss.sgi.com Subject: RE: TAKE - mount msgs Date: Tue, 4 Sep 2001 15:49:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Linus himself seems to want to eliminate "good status" messages from kernel boot... http://marc.theaimsgroup.com/?l=linux-kernel&m=99374815219617&w=2 --Josh > -----Original Message----- > From: Blizbor [mailto:tb670725@ima.pl] > Sent: Tuesday, September 04, 2001 8:44 AM > To: linux-xfs@oss.sgi.com > Subject: Re: TAKE - mount msgs > > > At 9/4/01 04:39 PM, Ethan Benson wrote: > >On Tue, Sep 04, 2001 at 04:23:02PM +0200, Andi Kleen wrote: > >> > >> The point is that you can quickly blame XFS for it ("it > crashed in XFS log > >> replay"). With no message it is a lot harder to find which > subsystem to > >> debug. > > > >so print the messages in debug mode, but not otherwise. > > > > Ethan, so what next ? > pppd authors ? ethernet drivers authors ? maybe guys doing scsi ? > What should be changed next to produce less initial output ? > From owner-linux-xfs@oss.sgi.com Tue Sep 4 16:48:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84NmR803909 for linux-xfs-outgoing; Tue, 4 Sep 2001 16:48:27 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84NmOd03886 for ; Tue, 4 Sep 2001 16:48:24 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id f84NmI527080 for ; Tue, 4 Sep 2001 16:48:18 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA03253; Wed, 5 Sep 2001 10:47:02 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA52461; Wed, 5 Sep 2001 10:47:00 +1100 (AEDT) Date: Wed, 5 Sep 2001 10:47:00 +1100 From: Nathan Scott To: Ethan Benson Cc: linux-xfs@oss.sgi.com Subject: Re: smaller mkfs.xfs Message-ID: <20010905104700.E324361@wobbly.melbourne.sgi.com> References: <20010904043952.V14519@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010904043952.V14519@plato.local.lan>; from erbenson@alaska.net on Tue, Sep 04, 2001 at 04:39:52AM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Tue, Sep 04, 2001 at 04:39:52AM -0800, Ethan Benson wrote: > > Is there any possible ways to reduce the size of the mkfs.xfs binary? > > I am working on adding support for direct XFS installation to the > Debian boot-floppies, but the size of mkfs.xfs is proving to be a real > problem (we are already very tight on space as it is). > > from what i can tell by briefly looking at it, libuuid appears to be > statically linked into this binary? is this correct? making this > dynamic would help a little (probably not much but i can use every > kbyte i can get). also its built with -O1 optimization, is there any > reason for this? would -Os be potentially problematic? > yes, you could link dynamically with libuuid, might help (esp. if you already have mkfs.ext2 on the floppy already, as this uses the same library). libuuid is not very big though, so I doubt this will help much in practice. I have never compiled userspace with -Os, so don't know whether that will cause issues for you - I have compiled at -O2 and I seem to recall some gcc versions broke xfs_db at that optimization level (looked like bad code from gcc) - in particular this was the 2.95.3 gcc in Debian unstable several months ago (long gone though). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Sep 4 17:06:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8506ia04422 for linux-xfs-outgoing; Tue, 4 Sep 2001 17:06:44 -0700 Received: from alaska.net (kitsune.nwc.alaska.net [209.112.130.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8506ed04402 for ; Tue, 4 Sep 2001 17:06:40 -0700 Received: from erbenson.alaska.net (97-pm18.nwc.alaska.net [209.112.142.97]) by alaska.net (8.9.1/8.9.1) with ESMTP id QAA07448 for ; Tue, 4 Sep 2001 16:06:37 -0800 (AKDT) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 757B13924 for ; Tue, 4 Sep 2001 16:06:33 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id AFC0910246; Tue, 4 Sep 2001 16:06:32 -0800 (AKDT) Date: Tue, 4 Sep 2001 16:06:32 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: smaller mkfs.xfs Message-ID: <20010904160632.I14519@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20010904043952.V14519@plato.local.lan> <20010905104700.E324361@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kTN++mu+z+U/mv0o" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010905104700.E324361@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Wed, Sep 05, 2001 at 10:47:00AM +1100 X-OS: Debian GNU Mail-Copies-To: nobody Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --kTN++mu+z+U/mv0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 05, 2001 at 10:47:00AM +1100, Nathan Scott wrote: > yes, you could link dynamically with libuuid, might help > (esp. if you already have mkfs.ext2 on the floppy already, > as this uses the same library). libuuid is not very big > though, so I doubt this will help much in practice. i could help just enough combined with other bloat reduction im looking into. =20 > I have never compiled userspace with -Os, so don't know > whether that will cause issues for you - I have compiled > at -O2 and I seem to recall some gcc versions broke xfs_db > at that optimization level (looked like bad code from gcc) > - in particular this was the 2.95.3 gcc in Debian unstable > several months ago (long gone though). yes 2.95.4 is whats there now.. is there any kind of regression testing i can do to see if any bugs are introduced by -Os ? --=20 Ethan Benson http://www.alaska.net/~erbenson/ --kTN++mu+z+U/mv0o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuVbIgACgkQJKx7GixEevw2EQCeIFgd7Z3W/jxbJcf7M4Y0fX6I a9UAoIqfkNbZke0JxRk24OhtwObwHgIG =DodV -----END PGP SIGNATURE----- --kTN++mu+z+U/mv0o-- From owner-linux-xfs@oss.sgi.com Tue Sep 4 18:52:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f851q0L06742 for linux-xfs-outgoing; Tue, 4 Sep 2001 18:52:00 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f851pwd06723 for ; Tue, 4 Sep 2001 18:51:58 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA02710 for ; Tue, 4 Sep 2001 18:50:20 -0700 (PDT) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA25920 for linux-xfs@oss.sgi.com; Wed, 5 Sep 2001 11:50:39 +1000 (EST) Date: Wed, 5 Sep 2001 11:50:39 +1000 (EST) From: Timothy Shimmin Message-Id: <200109050150.LAA25920@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - cmd/xfstests/common.dump Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Sep 4 18:50:05 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102157a cmd/xfstests/common.dump - 1.14 - specify scratch_dev on mount - don't rely on fstab or mtab. From owner-linux-xfs@oss.sgi.com Tue Sep 4 18:58:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f851wBB06959 for linux-xfs-outgoing; Tue, 4 Sep 2001 18:58:11 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f851w9d06940 for ; Tue, 4 Sep 2001 18:58:09 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id f851w3J08296 for ; Tue, 4 Sep 2001 18:58:04 -0700 Received: from smack.melbourne.sgi.com (smack.melbourne.sgi.com [134.14.55.210]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA03918; Wed, 5 Sep 2001 12:56:47 +1100 Received: from localhost (mg@localhost) by smack.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA38265; Wed, 5 Sep 2001 11:56:47 +1000 (EST) Date: Wed, 5 Sep 2001 11:56:46 +1000 From: Mike Gigante To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: man pages on reality (was Re: Preallocation of space) In-Reply-To: <3B94F5D7.C4E4CD75@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 4 Sep 2001, Eric Sandeen wrote: > If you want to use it as a reference, save it locally... reality *might* > going away... :( > > -Eric Reality *is* going away soon. It has been confirmed on the reality mailing list by senior management. Mike From owner-linux-xfs@oss.sgi.com Wed Sep 5 01:03:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8583en16039 for linux-xfs-outgoing; Wed, 5 Sep 2001 01:03:40 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8583Zd15992 for ; Wed, 5 Sep 2001 01:03:35 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id BAA01624 for ; Wed, 5 Sep 2001 01:01:58 -0700 (PDT) mail_from (ivanr@melbourne.sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA06005; Wed, 5 Sep 2001 19:02:17 +1100 From: ivanr@melbourne.sgi.com (Ivan Rayner) Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id SAA57126; Wed, 5 Sep 2001 18:02:16 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Wed, 5 Sep 2001 18:02:15 +1000 To: Matteo Centonza cc: Subject: Re: xfsdump question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 27 Aug 2001, Matteo Centonza wrote: > | xfsdump: creating dump session media file 0 (media 0, file 0) > | xfsdump: dumping ino map > | xfsdump: dumping directories > | xfsdump: dumping non-directory files > | xfsdump: WARNING: could not open regular file ino 17048187 mode > 0x000081a4: No such file or directory: not dumped > | xfsdump: WARNING: could not open regular file ino 17048190 mode > 0x000081a4: No such file or directory: not dumped > | xfsdump: WARNING: could not open regular file ino 17109993 mode > 0x000081a4: No such file or directory: not dumped > | xfsdump: ending media file > | xfsdump: media file size 6217415200 bytes > | xfsdump: dump size (non-dir files) : 6188187768 bytes > | xfsdump: dump complete: 1135 seconds elapsed ... > getting rid of quota informations which probably has a path problem, > the strange thing is that xfsdump doesn't dump three files that i'm > able to pick up with find: > > xxxxx:/home# find /home -inum 17048187 > /xxxx/xxxxxx/.gnome/panel.d/default/Applet_7_Extern > > and so the remaining two. The same three files were mentioned in the last > week backup as not dumped too. > This filesystem is on a LVM'ed soft RAID5 array with quota enabled, using > CVS copy as of 2001-07-24 (kernel 2.4.7, xfsdump 1.1.2-0). We've had another look at this, and I'd like you to try something else. In the xfstests rpm, there's a program called bstat. It's job is to bulkstat the filesystem and for every directory and file, it compares the stat info with the info from bulkstat. (Bulkstat is an XFS specific system call which will return blocks of inode stat information, which is much faster than stat'ing every file.) The bstat program will also try to open each file in the same way that xfsdump does (using jdm_open, which is a method of opening a file using only the inode number, rather than a pathname). Run bstat like so (assuming /home is an xfs filesystem): # ./bstat -c /home/[some_file_in_the_filesystem] > bstat.log bstat will output a tonne of info, so be sure to redirect it to a log file. When it's done, take a look to see if you can find any failures in the log (look for "unable"). This info could be interesting. Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Wed Sep 5 02:01:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8591XP17190 for linux-xfs-outgoing; Wed, 5 Sep 2001 02:01:33 -0700 Received: from mail.loewe-komp.de (mail.loewe-komp.de [62.156.155.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8591Td17171 for ; Wed, 5 Sep 2001 02:01:29 -0700 Received: from loewe-komp.de (pippin.loewe-komp.de [192.168.169.19]) by mail.loewe-komp.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id f8597wU30966; Wed, 5 Sep 2001 11:08:02 +0200 X-Authentication-Warning: mail.loewe-komp.de: Host pippin.loewe-komp.de [192.168.169.19] claimed to be loewe-komp.de Message-ID: <3B95EA01.15350CE@loewe-komp.de> Date: Wed, 05 Sep 2001 11:01:53 +0200 From: Peter =?iso-8859-1?Q?W=E4chtler?= Organization: LOEWE. Hannover X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.9-ac3 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: Seth Mos CC: XFS mailing list Subject: Re: System lock while accessing files causes file corruption References: <3B94F726.E978C299@sgi.com> <85063BBE668FD411944400D0B744267A888526@AUSMAIL> <3B94F726.E978C299@sgi.com> <4.3.2.7.2.20010904193203.032499a0@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > > At 17:57 4-9-2001 +0200, utz lehmann wrote: > >Hi Eric > > > >Eric Sandeen [sandeen@sgi.com] wrote: > > > But in any case, it occurred to me that you could make /etc on it's own > > > partition, and mount that O_SYNC - I don't think that would be too much > > > overhead, /etc doesn't get written that much on a normal system (?). If > > > Oracle puts config files elsewhere, you could simlink them onto this > > > filesystem. > > > >You can't make /etc on a different partition than /. > >/etc, /sbin, /dev (without devfs) must on the / partition otherwise your > >system will not boot. > > If you use a decent layout fopr your data it does not matter. > If you have a separate /usr /var /tmp /home like most servers do you could > just mount your / fs O_SYNC since it would only have a _very_ slight > performance loss since you almost never write to the root fs. :-) > What about the access time? If you mount your / with sync,noatime then it only gets changed when users are logging in (chown user.group /dev/pty and alike). But yes, it's still acceptable ;) From owner-linux-xfs@oss.sgi.com Wed Sep 5 02:25:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f859PEj17641 for linux-xfs-outgoing; Wed, 5 Sep 2001 02:25:14 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f859PAd17622 for ; Wed, 5 Sep 2001 02:25:10 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id LAA22000; Wed, 5 Sep 2001 11:25:03 +0200 (CEST) Message-Id: <4.3.2.7.2.20010905112116.033227e0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Sep 2001 11:25:12 +0200 To: Peter =?iso-8859-1?Q?W=E4chtler?= From: Seth Mos Subject: Re: System lock while accessing files causes file corruption Cc: XFS mailing list In-Reply-To: <3B95EA01.15350CE@loewe-komp.de> References: <3B94F726.E978C299@sgi.com> <85063BBE668FD411944400D0B744267A888526@AUSMAIL> <3B94F726.E978C299@sgi.com> <4.3.2.7.2.20010904193203.032499a0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f859PBd17623 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:01 5-9-2001 +0200, Peter Wächtler wrote: >Seth Mos wrote: > > If you use a decent layout fopr your data it does not matter. > > If you have a separate /usr /var /tmp /home like most servers do you could > > just mount your / fs O_SYNC since it would only have a _very_ slight > > performance loss since you almost never write to the root fs. :-) > > > >What about the access time? If you mount your / with sync,noatime >then it only gets changed when users are logging in >(chown user.group /dev/pty and alike). > >But yes, it's still acceptable ;) Remember, these operations are metadata operations and these _do_ get journaled. It's just to protect the the data files from magically getting emptied if you had just touched them. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Sep 5 05:53:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85CrT521125 for linux-xfs-outgoing; Wed, 5 Sep 2001 05:53:29 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85CrOd21106 for ; Wed, 5 Sep 2001 05:53:24 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id C80A0C00FA5 for ; Wed, 5 Sep 2001 20:53:21 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 87CA1C00FA4 for ; Wed, 5 Sep 2001 20:53:19 +0800 (PHT) Date: Wed, 5 Sep 2001 20:53:19 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: kernel spam when mounting xfs In-Reply-To: <20010904162714.A1567@agestado.com.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 4 Sep 2001 at 16:27, Adriano Nagelschmidt Rodrigues wrote: > Ok, I'll bite, I use ReiserFS and I'm new to this list. Aha! Another target for conversion. Just kidding. I'm also new to the list (especially relative to the real gurus like Eric, Nathan, Steve or Seth, among others), but not quite as new as you I guess. ;> I started out using ReiserFS before XFS because ReiserFS was around in the Linux scene before XFS. I tested XFS when it first got out, wasn't satisfied by the speed (because I felt the significant delete hit), and reverted to ReiserFS. This was with my old server. I got a new server after that and had to decide which filesystem to use. I chose XFS for most everything except my boot partition which uses ext2 and my Squid cache which uses ReiserFS (because ReiserFS has phenomenal delete speeds). > What are the technical reasons not to use ReiserFS? There are a number, and these all depend on your usage patterns. For starters you may want to check the mongo.pl benchmarks in the Namesys (ReiserFS) webpage. ReiserFS is great for small files but you will note that except for delete performance, XFS will start beating ReiserFS at around 10000 bytes. That's rougly 10KB, and for a number of systems (like my Samba+NFS data partition), that's small enough. XFS is stable with NFS. I've done relatively small stress tests and know that for loads beyond our typical here, XFS+NFS is stable. Others like Dan Yocum, who is also on the list, I believe have done even more XFS+NFS stress testing. ReiserFS is supposed to be approaching stability with NFS, but ... XFS has stuff like ACLs, and you'll need to wait for Reiser4 to get that. I made a small talk for the local Linux10 celebrations. If you're interested you can go to to take a look at my slides. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Wed Sep 5 07:00:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85E0EB22300 for linux-xfs-outgoing; Wed, 5 Sep 2001 07:00:14 -0700 Received: from seralph5.essex.ac.uk (seralph5.essex.ac.uk [155.245.240.155]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85E0Ad22279 for ; Wed, 5 Sep 2001 07:00:10 -0700 Received: from sernt14.essex.ac.uk ([155.245.240.183]) by seralph5.essex.ac.uk with esmtp (Exim 3.13 #1) id 15edDg-0007II-00 for linux-xfs@oss.sgi.com; Wed, 05 Sep 2001 14:59:56 +0100 Received: by sernt14.essex.ac.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Sep 2001 14:57:41 +0100 Message-ID: <7AC902A40BEDD411A3A800D0B7847B660882F5@sernt14.essex.ac.uk> From: "Giddings, Bret" To: "'linux-xfs@oss.sgi.com'" Subject: XFS, Quotas and Samba Date: Wed, 5 Sep 2001 14:57:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am investigating whether I can replace my expensive Compaq Alphas file servers with cheaper (and invariably faster given my budget) Intel based ones. I have so far been pleased with the ease with which xfs has installed and run on my hardware of choice. To make my life easier, I have picked up the pre-built RedHat kernels with xfs support. Everything appears to be fine except that when connecting to a share from Samba, the amount of free space reported is the amount of free disk space left on the device rather than the amount of free space in the users quota (this is on a disk mounted with usrquota and a quota set for the users). The usual tools (edquota, setquota work as expected). I have downloaded the source rpm for samba and it appears that RedHat build their smbd to support quotas. I have also checked whether /usr/include/sys/quota.h is modified by installing your updated quota rpm (quota-3.01pre8) and it isn't. So, is there another reason why quotas don't appear to work with xfs/samba? Thanks in advance, Bret -- Bret Giddings, Systems Manager, Computing Service, University of Essex Tel: (01206) 872577 Email: bret@essex.ac.uk Fax: (01206) 860585 From owner-linux-xfs@oss.sgi.com Wed Sep 5 08:04:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85F4se23436 for linux-xfs-outgoing; Wed, 5 Sep 2001 08:04:54 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85F4od23416 for ; Wed, 5 Sep 2001 08:04:51 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id E1F0F1E3E4; Wed, 5 Sep 2001 17:04:44 +0200 (MEST) Date: Wed, 5 Sep 2001 17:04:27 +0200 From: Andi Kleen To: Federico Sevilla III Cc: Linux XFS Mailing List Subject: Re: kernel spam when mounting xfs Message-ID: <20010905170427.A20994@gruyere.muc.suse.de> References: <20010904162714.A1567@agestado.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jijo@leathercollection.ph on Wed, Sep 05, 2001 at 08:53:19PM +0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Sep 05, 2001 at 08:53:19PM +0800, Federico Sevilla III wrote: > XFS is stable with NFS. I've done relatively small stress tests and know > that for loads beyond our typical here, XFS+NFS is stable. Others like Dan > Yocum, who is also on the list, I believe have done even more XFS+NFS > stress testing. ReiserFS is supposed to be approaching stability with NFS, > but ... Just to stop the FUD a bit: The last known reiserfs NFS problem (not being able to resolve file handles again under heavy load) has been fixed with 2.4.5. Before that it has been several years been documented as being fixable with a patch. The basic problem BTW was that Linux cannot handle 64bit inode numbers. XFS runs into the same problem when you start using filesystems >2TB. -Andi From owner-linux-xfs@oss.sgi.com Wed Sep 5 08:05:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85F5jI23548 for linux-xfs-outgoing; Wed, 5 Sep 2001 08:05:45 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85F5hd23526 for ; Wed, 5 Sep 2001 08:05:43 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f85F5b520015 for ; Wed, 5 Sep 2001 08:05:38 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2893275; Wed, 5 Sep 2001 10:04:22 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA57772; Wed, 5 Sep 2001 10:04:21 -0500 (CDT) Message-ID: <3B963E97.B99B4FA0@sgi.com> Date: Wed, 05 Sep 2001 10:02:47 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Ethan Benson CC: linux-xfs@oss.sgi.com Subject: Re: smaller mkfs.xfs References: <20010904043952.V14519@plato.local.lan> <20010905104700.E324361@wobbly.melbourne.sgi.com> <20010904160632.I14519@plato.local.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ethan Benson wrote: > yes 2.95.4 is whats there now.. is there any kind of regression > testing i can do to see if any bugs are introduced by -Os ? There is a suite of tests under cmd/xfstests, edit common.config for your machine, and then just run ./check 0?? - none of this is specifically designed to test -0s, but it will make filesystems and check them in various ways... it would be a place to start, in any case. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Sep 5 08:19:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85FJmJ23908 for linux-xfs-outgoing; Wed, 5 Sep 2001 08:19:48 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85FJhd23889 for ; Wed, 5 Sep 2001 08:19:43 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 9A0F1C00FA5; Wed, 5 Sep 2001 23:19:41 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 3F89BC00FA4; Wed, 5 Sep 2001 23:19:40 +0800 (PHT) Date: Wed, 5 Sep 2001 23:19:40 +0800 (PHT) From: Federico Sevilla III To: Dan Yocum Cc: Linux XFS Mailing List , "Philippine Linux Users' Group Mailing List" Subject: On RAID, inode size, stripe size (was: Playing around with NFS+XFS) In-Reply-To: <3B953C69.BBACF47@fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dan, (cc PLUG, XFS mailing lists) On Tue, 4 Sep 2001 at 15:41, yocum@fnal.gov wrote: > That's the best you'll get out of your 3ware 6400 card under RAID5, so > your bottleneck is the card, not the network, here. :-( Ugh! Ouch. Boohoohoo. I presume this has something to do with the on-board controller and/or the algorithm they use? :( > If you want good performance out of a 3ware card, use RAID 1 or 10 (if > you have a 6x00 card) or get a 7x10, which will do about 17MB/s in > RAID5. It's still not great, but a lot better than 6MB/s. RAID1/10 > on the 7810 is >>100MB/s for writes, and about 180MB/s reads. D*mn! Information like this makes me wonder why I chose RAID5 anyway. I guess it's because I didn't have access to such information before making the decision, and with RAID5 I get significantly more disk space so I said, what the heck. Perhaps I will find the time to take the server offline in the not-so-far-away future to back up all the data onto some hard drives and then re-do the RAID so that it'll be RAID10, which aside from being much faster, is more fault tolerant in that as long as you don't get the right pair, it can handle two drives down. Maybe you're the expert for this: what is RAID5 good for then? And no, I don't think I can afford to upgrade to RAID50 like you. ;> > So, here's what I get for performance on NFSv3 over gigabit ethernet > to XFS (I didn't tweak the r/wmem_default values, only the r/wmem_max. I presume only tweaking the r/wmem_max is safer than meddling with the defaults? > The XFS volume is RAID50, hw RAID5, then sw RAID0 (striped), hence the > reason I can get >17MB/s. I used a 512kb chunksize for the sw RAID0, > but I think I might be able to get better performance if I used 448kb. > *and* no data/inode corruption now that '-i size=512' now. Would you mind explaining to my young mind how using an inode size of 512 bytes protects from data/inode corruption with hardware RAID5? Will this be significant for other setups (hardware RAID10, software RAID, no RAID at all)? Does this have any major disk space or performance impacts? Also with the 3ware 6x00 controllers, RAID5 is limited to 64K stripe size, while RAID0 and RAID10 use 64K, 128K, 256K, 512K or 1M stripe size. How does the stripe size of hardware RAID affect performance and disk utilization? And how can/should the filesystem be tuned to "match" the stripe size of hardware RAID? I'm full of questions. Thanks a lot for the info (that you already gave and that you will hopefully continue to give, hehehe). ;> --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Wed Sep 5 08:25:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85FPXI24105 for linux-xfs-outgoing; Wed, 5 Sep 2001 08:25:33 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85FPUd24086 for ; Wed, 5 Sep 2001 08:25:30 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id C8913C00FA5; Wed, 5 Sep 2001 23:25:28 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 6618EC00FA4; Wed, 5 Sep 2001 23:25:27 +0800 (PHT) Date: Wed, 5 Sep 2001 23:25:27 +0800 (PHT) From: Federico Sevilla III To: Andi Kleen Cc: Linux XFS Mailing List Subject: Re: kernel spam when mounting xfs In-Reply-To: <20010905170427.A20994@gruyere.muc.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 5 Sep 2001 at 17:04, Andi Kleen wrote: > Just to stop the FUD a bit: Oops. I didn't mean that as FUD but now that I think about it, it was. My sincerest apologies, and thank you very much Andi for that wakeup call. > The last known reiserfs NFS problem (not being able to resolve file > handles again under heavy load) has been fixed with 2.4.5. Before that > it has been several years been documented as being fixable with a > patch. I was not quite sure about the stability of ReiserFS+NFS despite the patches, but just checked and indeed the knfsd patches stopped at 2.4.5. > The basic problem BTW was that Linux cannot handle 64bit inode > numbers. So it is indeed more of a problem with the implementation of NFS on Linux than any of the filesystems? --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Wed Sep 5 08:40:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85FeBR24442 for linux-xfs-outgoing; Wed, 5 Sep 2001 08:40:11 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85Fe3d24422 for ; Wed, 5 Sep 2001 08:40:03 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f85FdvJ28760 for ; Wed, 5 Sep 2001 08:39:57 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2881244; Wed, 5 Sep 2001 10:38:41 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA89218; Wed, 5 Sep 2001 10:38:41 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f85FaOO05864; Wed, 5 Sep 2001 10:36:24 -0500 Message-Id: <200109051536.f85FaOO05864@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Federico Sevilla III cc: Dan Yocum , Linux XFS Mailing List , "Philippine Linux Users' Group Mailing List" Subject: Re: On RAID, inode size, stripe size (was: Playing around with NFS+XFS) In-Reply-To: Message from Federico Sevilla III of "Wed, 05 Sep 2001 23:19:40 +0800." Date: Wed, 05 Sep 2001 10:36:24 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Would you mind explaining to my young mind how using an inode size of 512 > bytes protects from data/inode corruption with hardware RAID5? Will this > be significant for other setups (hardware RAID10, software RAID, no RAID > at all)? Does this have any major disk space or performance impacts? > This is not a raid5 thing, it is a filesystem size issue, once you get above 1 Tbyte in filesystem size then xfs inode numbers (which are really a disk address) can take more than 32 bits. Since lots of linux code, including NFS, does not cope with this, we need to change things in xfs so that a larger inode is used, this reduces the number of addressing bits required down to below 32 bits again. This is an interim measure, we have a design for keeping inodes down in the low part of the filesystem (low Tbyte that is) to avoid the address space overflow. Steve From owner-linux-xfs@oss.sgi.com Wed Sep 5 08:49:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85FnAq24802 for linux-xfs-outgoing; Wed, 5 Sep 2001 08:49:10 -0700 Received: from mail.loewe-komp.de (mail.loewe-komp.de [62.156.155.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85Fn5d24780 for ; Wed, 5 Sep 2001 08:49:05 -0700 Received: from loewe-komp.de (pippin.loewe-komp.de [192.168.169.19]) by mail.loewe-komp.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id f85FtjU00724 for ; Wed, 5 Sep 2001 17:55:45 +0200 X-Authentication-Warning: mail.loewe-komp.de: Host pippin.loewe-komp.de [192.168.169.19] claimed to be loewe-komp.de Message-ID: <3B964994.CAD96E21@loewe-komp.de> Date: Wed, 05 Sep 2001 17:49:40 +0200 From: Peter =?iso-8859-1?Q?W=E4chtler?= Organization: LOEWE. Hannover X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.9-ac3 i686) X-Accept-Language: de, en MIME-Version: 1.0 CC: Linux XFS Mailing List Subject: Re: kernel spam when mounting xfs References: <20010904162714.A1567@agestado.com.br> <20010905170427.A20994@gruyere.muc.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andi Kleen wrote: > > On Wed, Sep 05, 2001 at 08:53:19PM +0800, Federico Sevilla III wrote: > > XFS is stable with NFS. I've done relatively small stress tests and know > > that for loads beyond our typical here, XFS+NFS is stable. Others like Dan > > Yocum, who is also on the list, I believe have done even more XFS+NFS > > stress testing. ReiserFS is supposed to be approaching stability with NFS, > > but ... > > Just to stop the FUD a bit: > > The last known reiserfs NFS problem (not being able to resolve file handles > again under heavy load) has been fixed with 2.4.5. Before that > it has been several years been documented as being fixable with a patch. > The basic problem BTW was that Linux cannot handle 64bit inode numbers. > XFS runs into the same problem when you start using filesystems >2TB. > Another topic that scares me: Is gcc 2.95.[23] considered bad to compile xfs? Why is egcs-2.91-something recommended? I use 2.4.3-xfs on an i686 SMP machine as NFS server, and I had at least two hard lockups (the last happened when mounting a CDROM on aic7xxx). Now if I want to give 2.4.9 a try: do I have to use egcs-2.91 (not there on SuSE)? From owner-linux-xfs@oss.sgi.com Wed Sep 5 09:01:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85G1o225135 for linux-xfs-outgoing; Wed, 5 Sep 2001 09:01:50 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85G1ld25115 for ; Wed, 5 Sep 2001 09:01:47 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 34C7BC00FA5 for ; Thu, 6 Sep 2001 00:01:46 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id BE893C00FA4 for ; Thu, 6 Sep 2001 00:01:44 +0800 (PHT) Date: Thu, 6 Sep 2001 00:01:44 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: On RAID, inode size, stripe size (was: Playing around with NFS+XFS) In-Reply-To: <200109051536.f85FaOO05864@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 5 Sep 2001 at 10:36, Steve Lord wrote: > This is not a raid5 thing, it is a filesystem size issue, once you get > above 1 Tbyte in filesystem size then xfs inode numbers (which are > really a disk address) can take more than 32 bits. Since lots of linux > code, including NFS, does not cope with this, we need to change things > in xfs so that a larger inode is used, this reduces the number of > addressing bits required down to below 32 bits again. So on filesystems <1TB you can safely use the default of 256 bytes? --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Wed Sep 5 09:07:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85G70425319 for linux-xfs-outgoing; Wed, 5 Sep 2001 09:07:00 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85G6vd25300 for ; Wed, 5 Sep 2001 09:06:57 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA07687 for ; Wed, 5 Sep 2001 09:06:36 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA2890233; Wed, 5 Sep 2001 11:05:15 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA40992; Wed, 5 Sep 2001 11:05:15 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f85G2wX05922; Wed, 5 Sep 2001 11:02:58 -0500 Message-Id: <200109051602.f85G2wX05922@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Federico Sevilla III cc: Linux XFS Mailing List Subject: Re: On RAID, inode size, stripe size (was: Playing around with NFS+XFS) In-Reply-To: Message from Federico Sevilla III of "Thu, 06 Sep 2001 00:01:44 +0800." Date: Wed, 05 Sep 2001 11:02:58 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Wed, 5 Sep 2001 at 10:36, Steve Lord wrote: > > This is not a raid5 thing, it is a filesystem size issue, once you get > > above 1 Tbyte in filesystem size then xfs inode numbers (which are > > really a disk address) can take more than 32 bits. Since lots of linux > > code, including NFS, does not cope with this, we need to change things > > in xfs so that a larger inode is used, this reduces the number of > > addressing bits required down to below 32 bits again. > > So on filesystems <1TB you can safely use the default of 256 bytes? Yes, also mkfs has recently been changed to do this automatically, so provided someones mkfs has been updated recently enough, this scenario should not arise anymore. At least until Linux support 16 Tbyte devices at which point the more complex fix is needed. Steve > > --> Jijo > > -- > Federico Sevilla III :: jijo@leathercollection.ph > Network Administrator :: The Leather Collection, Inc. > GnuPG Key: From owner-linux-xfs@oss.sgi.com Wed Sep 5 09:20:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85GK4D25640 for linux-xfs-outgoing; Wed, 5 Sep 2001 09:20:04 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85GK1d25621 for ; Wed, 5 Sep 2001 09:20:01 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA01931 for ; Wed, 5 Sep 2001 09:18:24 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA2892993; Wed, 5 Sep 2001 11:18:43 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA67609; Wed, 5 Sep 2001 11:18:43 -0500 (CDT) Message-ID: <3B965004.3CF7AEBD@sgi.com> Date: Wed, 05 Sep 2001 11:17:08 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 CC: Federico Sevilla III , Linux XFS Mailing List Subject: Re: On RAID, inode size, stripe size (was: Playing around with NFS+XFS) References: <200109051602.f85G2wX05922@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > Yes, also mkfs has recently been changed to do this automatically, so > provided someones mkfs has been updated recently enough, this scenario > should not arise anymore. At least until Linux support 16 Tbyte devices > at which point the more complex fix is needed. And if you'd like to check an existing filesystem, the latest xfs_info will print the current inode size you can expect (the "imaxbits" line). Also, bear in mind that if you want to grow your filesystem later, you may hit the inode number size problem again. Doubling your filesystem size will add one bit to the maximum inode number, on average. So, if you make a filesystem at 1TB, but anticipate growing it to 4TB, you should choose an inode size of 1024 or so to give you some room in the bits. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Sep 5 09:21:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85GLu825779 for linux-xfs-outgoing; Wed, 5 Sep 2001 09:21:56 -0700 Received: from imapserverb.fnal.gov (imapserverb.fnal.gov [131.225.9.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85GLnd25758 for ; Wed, 5 Sep 2001 09:21:49 -0700 Received: from imapserverb.fnal.gov ([131.225.9.17]) by imapserverb.fnal.gov (Netscape Messaging Server 4.15) with SMTP id GJ76SC00.M67 for ; Wed, 5 Sep 2001 11:21:48 -0500 Received: from fnal.gov ([131.225.7.82]) by imapserverb.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001090511214726611 ; Wed, 05 Sep 2001 11:21:47 -0500 Message-ID: <3B96511C.99471DEE@fnal.gov> Date: Wed, 05 Sep 2001 11:21:48 -0500 From: yocum@fnal.gov X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Federico Sevilla III , xfs-list Subject: Re: On RAID, inode size, stripe size (was: Playing around with NFS+XFS) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jijo, OK, I know we're off topic of the list (XFS) so lets take this to the ide-array list (majordomo@lists.math.uh.edu), after this response. Federico Sevilla III wrote: > > Dan, > (cc PLUG, XFS mailing lists) > > On Tue, 4 Sep 2001 at 15:41, yocum@fnal.gov wrote: > > That's the best you'll get out of your 3ware 6400 card under RAID5, so > > your bottleneck is the card, not the network, here. :-( > > Ugh! Ouch. Boohoohoo. I presume this has something to do with the on-board > controller and/or the algorithm they use? :( I talked to one of the 3ware VPs one day and he said that a) the 6x00 CPU is way underpowered to do RAID5 parity calculations at a decent speed, b) there's no on-board cache, and c) they've had troubles with the FPGAs on the cards. How the last item affects write speed I don't know, maybe he was complaining about their reliability. Anyway, the 7810 has a faster CPU and uses APICs instead of FPGAs, but still doesn't have an on-board cache. The 6x00 cards were made RAID5 capable through a firmware update after Promise came out with a RAID5 card. It was clearly a "me too!" reaction to the competition. > Maybe you're the expert for this: what is RAID5 good for then? And no, I We're more concerned with maximum filesystem size and _read_ speed since we'll write once, read *a lot*. Read speed on the 6x00 cards isn't terrible (85MB/s IIRC) but is even better under the 7x10 cards (180MB/s!!). > > > So, here's what I get for performance on NFSv3 over gigabit ethernet > > to XFS (I didn't tweak the r/wmem_default values, only the r/wmem_max. > > I presume only tweaking the r/wmem_max is safer than meddling with the > defaults? To be honest, I forgot to change the r/wmem_default values when I did the test. > > *and* no data/inode corruption now that '-i size=512' now. (hm. note to self: wipe out and erradicate superfluous redundancies) > > Would you mind explaining to my young mind how using an inode size of 512 > bytes protects from data/inode corruption with hardware RAID5? Will this Yeah, what Steve said. I just threw that comment in there so this thread sort-of remained on topic. Sorry for the confusion. Speaking of being off topic, I'm about to post a technical note on the ide-array list about the systems we've got and what I had to do to get them to where they are now (which is pretty damn stable). I'm pretty sure I've got all the major bugs taken care of (with lots of help from mkp and Eric and Adam at 3ware and....) > Also with the 3ware 6x00 controllers, RAID5 is limited to 64K stripe size, > while RAID0 and RAID10 use 64K, 128K, 256K, 512K or 1M stripe size. How > does the stripe size of hardware RAID affect performance and disk > utilization? And how can/should the filesystem be tuned to "match" the > stripe size of hardware RAID? No effect on utilization. Definitely a factor in speed, but specifics I don't know. In fact, I'm not sure any other RAID card manufacturer allows for anything other than 64k stripe size under RAID 5, but my RAID experience is admittedly limited. > > I'm full of questions. Thanks a lot for the info (that you already gave > and that you will hopefully continue to give, hehehe). ;> "And my consulting fee is.... " ;-) I'm just happy to have systems that I can turn on and forget at the moment. Get me back into the commercial world, and my tune may change. But, for the time being, I live in a purely open source, open information Xanadu! I have achieved Nirvana. Hooooommmmmmeeee, Hoooooommmmmmmeee. Cheers, Dan -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Wed Sep 5 13:31:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85KVCn31151 for linux-xfs-outgoing; Wed, 5 Sep 2001 13:31:12 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85KRUd31104; Wed, 5 Sep 2001 13:27:33 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 834F86703E; Wed, 5 Sep 2001 22:27:17 +0200 (CEST) Subject: Re: kernel spam when mounting xfs To: Peter =?iso-8859-1?Q?W=E4chtler?= Cc: Linux XFS Mailing List , owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Wed, 5 Sep 2001 22:27:16 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 05.09.2001 22:27:18 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f85KRbd31106 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 05.09.2001 17:49:40 Peter Wächtler wrote: >I use 2.4.3-xfs on an i686 SMP machine as NFS server, and I had at >least >two hard lockups (the last happened when mounting a CDROM on aic7xxx). >Now if I want to give 2.4.9 a try: do I have to use egcs-2.91 (not >there on SuSE)? Hi Peter, They told me to do so last week, fetch the following packages from redhat.com: kgcc-1.1.2-40.i386.rpm compat-egcs-6.2-1.1.2.9.i386.rpm compat-glibc-6.2-2.1.3.2.i386.rpm and install them with rpm -i it works fine for me on Suse 7.2! That kgcc will be used for compiling the kernel, look in the toplevel Makefile of the Kernel for kgcc and uncomment the line........ thats it ;-) cu micha -- Michael Wahlbrink IT Services Propack Data GmbH Karlsruhe miw@propack-data.com +49 721 9650-851 From owner-linux-xfs@oss.sgi.com Wed Sep 5 15:20:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85MKRP00668 for linux-xfs-outgoing; Wed, 5 Sep 2001 15:20:27 -0700 Received: from c4solutions.net (IDENT:qmailr@mail.c4solutions.net [216.143.5.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85MK2d00634 for ; Wed, 5 Sep 2001 15:20:23 -0700 Received: (qmail 26987 invoked by uid 100); 5 Sep 2001 22:19:10 -0000 To: linux-xfs@oss.sgi.com Subject: Installer Source Message-ID: <999728350.3b96a4de0bf70@www.c4solutions.net> Date: Wed, 05 Sep 2001 18:19:10 -0400 (EDT) From: Barrett Gay MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 216.143.5.139 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am trying to create a custom Redhat based distrobution and I would like to include support for XFS. I was wondering if the installer that is used for the SGi Redhat Install Disk is open-source and where I could get a copy of it. Thanks, Barrett Gay From owner-linux-xfs@oss.sgi.com Wed Sep 5 15:34:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85MYT601038 for linux-xfs-outgoing; Wed, 5 Sep 2001 15:34:29 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85MYQd01013 for ; Wed, 5 Sep 2001 15:34:26 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f85MYKJ19438 for ; Wed, 5 Sep 2001 15:34:21 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2883122; Wed, 5 Sep 2001 17:33:05 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA56672; Wed, 5 Sep 2001 17:33:04 -0500 (CDT) Message-ID: <3B96A7BF.21E1D341@sgi.com> Date: Wed, 05 Sep 2001 17:31:27 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Barrett Gay CC: linux-xfs@oss.sgi.com Subject: Re: Installer Source References: <999728350.3b96a4de0bf70@www.c4solutions.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Barrett Gay wrote: > > I am trying to create a custom Redhat based distrobution and > I would like to include support for XFS. I was wondering if > the installer that is used for the SGi Redhat Install Disk > is open-source and where I could get a copy of it. Barrett - Just grab the modified anaconda SRPM from our ftp site, it should be under the Release-1.0.1 directory. If you have the ISO image, it's on there as well. The patch for XFS is in the SRPM. Are you working on RH 7.1, or the latest RH beta? -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Sep 5 17:01:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8601o602670 for linux-xfs-outgoing; Wed, 5 Sep 2001 17:01:50 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8601Od02651 for ; Wed, 5 Sep 2001 17:01:25 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id QAA01275 for ; Wed, 5 Sep 2001 16:59:37 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA10138; Thu, 6 Sep 2001 10:59:53 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA63118; Thu, 6 Sep 2001 10:59:52 +1100 (AEDT) Date: Thu, 6 Sep 2001 10:59:52 +1100 From: Nathan Scott To: "Giddings, Bret" Cc: "'linux-xfs@oss.sgi.com'" , samba-technical@lists.samba.org Subject: Re: XFS, Quotas and Samba Message-ID: <20010906105952.B345981@wobbly.melbourne.sgi.com> References: <7AC902A40BEDD411A3A800D0B7847B660882F5@sernt14.essex.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7AC902A40BEDD411A3A800D0B7847B660882F5@sernt14.essex.ac.uk>; from bret@essex.ac.uk on Wed, Sep 05, 2001 at 02:57:39PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Wed, Sep 05, 2001 at 02:57:39PM +0100, Giddings, Bret wrote: > I am investigating whether I can replace my expensive Compaq Alphas file > servers with cheaper (and invariably faster given my budget) Intel based > ones. I have so far been pleased with the ease with which xfs has installed > and run on my hardware of choice. To make my life easier, I have picked up > the pre-built RedHat kernels with xfs support. Everything appears to be fine > except that when connecting to a share from Samba, the amount of free space > reported is the amount of free disk space left on the device rather than the > amount of free space in the users quota (this is on a disk mounted with > usrquota and a quota set for the users). The usual tools (edquota, setquota > work as expected). > > I have downloaded the source rpm for samba and it appears that RedHat build > their smbd to support quotas. I have also checked whether > /usr/include/sys/quota.h is modified by installing your updated quota rpm > (quota-3.01pre8) and it isn't. So, is there another reason why quotas don't > appear to work with xfs/samba? The samba code needs to be updated to support XFS quota under Linux. There was someone on the list a little while ago who was looking to add in the samba support for XFS quota, but I don't know how far they got. I know very little about samba unfortunately, but it should be quite simple to add this stuff for XFS - the disk_quotas() routine in samba-2.2.1a/source/smbd/quotas.c is all that needs to be changed, by the look of things. For XFS filesystems on Linux this needs to: - have logic to handle getmntent's of type "xfs" separately; - issue a quotactl(QCMD(Q_XGETQUOTA,USRQUOTA), ..., &xdq) where xdq is of type "struct fs_disk_quota_t" from - set *bsize to 512 for XFS - refer to the code later in that same file for dealing with XFS on IRIX - basically, do exactly the same thing and it should just work. - to do it properly, the configure scripts will need to check for linux/xqm.h (or might be simpler to keep a local copy? - I dunno what sort of policy the samba folk have on this sort of thing, but this header isn't going to change and probably isn't going to appear in the libc headers for quite awhile...) cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Sep 5 18:36:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f861arJ04870 for linux-xfs-outgoing; Wed, 5 Sep 2001 18:36:53 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f861ald04851 for ; Wed, 5 Sep 2001 18:36:47 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f861ad506957 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Wed, 5 Sep 2001 18:36:40 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id DAA24009 for ; Thu, 6 Sep 2001 03:36:41 +0200 (CEST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA10829; Thu, 6 Sep 2001 12:35:16 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA72785; Thu, 6 Sep 2001 12:35:15 +1100 (AEDT) Date: Thu, 6 Sep 2001 12:35:15 +1100 From: Nathan Scott To: Jan Kara Cc: "'linux-xfs@oss.sgi.com'" , samba-technical@lists.samba.org Subject: Re: XFS, Quotas and Samba Message-ID: <20010906123515.A380241@wobbly.melbourne.sgi.com> References: <7AC902A40BEDD411A3A800D0B7847B660882F5@sernt14.essex.ac.uk> <20010906105952.B345981@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010906105952.B345981@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Thu, Sep 06, 2001 at 10:59:52AM +1100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Jan, Just a quick followup - this is what I mentioned in my earlier mail to you. I think your new VFS quota code (as in Alan Cox's series of 2.4 kernels, for the Samba folk) will have exactly the same problem as XFS. This "grep" would seem to confirm it - but you'll know better than I here: 11:31 nathans@troppo ~/cvs/quota-tools 73> grep GETQUOTA dqblk*h dqblk_rpc.h:#define Q_RPC_GETQUOTA 0x0300 /* get limits and usage */ dqblk_v1.h:#define Q_V1_GETQUOTA 0x300 dqblk_v2.h:#define Q_V2_GETQUOTA 0x0D00 /* Get limits and usage */ dqblk_xfs.h:#define Q_XFS_GETQUOTA Q_XGETQUOTA 11:31 nathans@troppo ~/cvs/quota-tools 74> The samba code does a good old Q_GETQUOTA (ie. your V1 above). cheers. On Thu, Sep 06, 2001 at 10:59:52AM +1100, Nathan Scott wrote: > hi, > > On Wed, Sep 05, 2001 at 02:57:39PM +0100, Giddings, Bret wrote: > > I am investigating whether I can replace my expensive Compaq Alphas file > > servers with cheaper (and invariably faster given my budget) Intel based > > ones. I have so far been pleased with the ease with which xfs has installed > > and run on my hardware of choice. To make my life easier, I have picked up > > the pre-built RedHat kernels with xfs support. Everything appears to be fine > > except that when connecting to a share from Samba, the amount of free space > > reported is the amount of free disk space left on the device rather than the > > amount of free space in the users quota (this is on a disk mounted with > > usrquota and a quota set for the users). The usual tools (edquota, setquota > > work as expected). > > > > I have downloaded the source rpm for samba and it appears that RedHat build > > their smbd to support quotas. I have also checked whether > > /usr/include/sys/quota.h is modified by installing your updated quota rpm > > (quota-3.01pre8) and it isn't. So, is there another reason why quotas don't > > appear to work with xfs/samba? > > The samba code needs to be updated to support XFS quota under > Linux. There was someone on the list a little while ago who > was looking to add in the samba support for XFS quota, but I > don't know how far they got. > > I know very little about samba unfortunately, but it should be > quite simple to add this stuff for XFS - the disk_quotas() > routine in samba-2.2.1a/source/smbd/quotas.c is all that needs > to be changed, by the look of things. > > For XFS filesystems on Linux this needs to: > - have logic to handle getmntent's of type "xfs" separately; > - issue a quotactl(QCMD(Q_XGETQUOTA,USRQUOTA), ..., &xdq) where > xdq is of type "struct fs_disk_quota_t" from > - set *bsize to 512 for XFS > - refer to the code later in that same file for dealing with XFS > on IRIX - basically, do exactly the same thing and it should > just work. > - to do it properly, the configure scripts will need to check > for linux/xqm.h (or might be simpler to keep a local copy? - > I dunno what sort of policy the samba folk have on this sort of > thing, but this header isn't going to change and probably isn't > going to appear in the libc headers for quite awhile...) > > cheers. > > -- > Nathan -- Nathan From owner-linux-xfs@oss.sgi.com Wed Sep 5 19:28:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f862SDS05708 for linux-xfs-outgoing; Wed, 5 Sep 2001 19:28:13 -0700 Received: from plato.arts.usyd.edu.au (plato.arts.usyd.edu.au [129.78.16.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f862S6d05688 for ; Wed, 5 Sep 2001 19:28:07 -0700 Received: from arts.usyd.edu.au (IDENT:matthew@whitestar.arts.usyd.edu.au [129.78.16.20]) by plato.arts.usyd.edu.au (8.9.3/8.9.3) with ESMTP id MAA18490; Thu, 6 Sep 2001 12:28:01 +1000 (EST) Message-ID: <3B96E0AF.20DF0FBF@arts.usyd.edu.au> Date: Thu, 06 Sep 2001 12:34:23 +1000 From: Matthew Geier Organization: Arts IT Unit, Sydney University X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7-pre6-xfs i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: "Giddings, Bret" CC: "'linux-xfs@oss.sgi.com'" Subject: Re: XFS, Quotas and Samba References: <7AC902A40BEDD411A3A800D0B7847B660882F5@sernt14.essex.ac.uk> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms9D010F1D9EE124DC7B2A3473" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms9D010F1D9EE124DC7B2A3473 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Giddings, Bret" wrote: > > I have downloaded the source rpm for samba and it appears that RedHat build > their smbd to support quotas. I have also checked whether > /usr/include/sys/quota.h is modified by installing your updated quota rpm > (quota-3.01pre8) and it isn't. So, is there another reason why quotas don't > appear to work with xfs/samba? yes. XFS quotas work differently from other Linux file system Quotas. I've hacked a 2.2.1a quota.c to support XFS quotas and it seems to work for me. It was a QOD patch though, it basicly replaced parts of the Linux quota code with bits taken out of the SGI quota section, thus ext2 quotas would be broken. I think I posted a diff to samba'a quota.c here a while back. If you are interested I could email you my quota.c. -- Matthew Geier matthew@arts.usyd.edu.au Arts IT Unit +61 2 9351 4713 Sydney University --------------ms9D010F1D9EE124DC7B2A3473 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH0AYJKoZIhvcNAQcCoIIHwTCCB70CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BbswggKKMIIB86ADAgECAgMFMYswDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTA3MDkxOTEyNThaFw0wMjA3MDkxOTEyNTha MEoxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxJzAlBgkqhkiG9w0BCQEWGG1h dHRoZXdAYXJ0cy51c3lkLmVkdS5hdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1H+o MQ4xn5lDS/7p9rYboPW7grw13lXOj7Xisip37QttkX7Ga3ITBXnsAKnuFK3Z7GtILACBXil1 BngLBOd0AlW9zqQBXEOP9aODNJzBsTb3+tOHwQo6shcORKQArKEinG00SuwBdzxALU3KWT6E yIUSvoz7q0PN4C8qUF3t00sCAwEAAaM1MDMwIwYDVR0RBBwwGoEYbWF0dGhld0BhcnRzLnVz eWQuZWR1LmF1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAiJu7SNBXsW7I+ZH9 e2+0M47BmR3DxV31VbW9mKcwuamusWSJJEy5MAKZc8b0snRX/XDkCpM+av3VxDJX8T3rxOE0 siyCC6Tclu6wjwjw0goXK4N6Xhsz+qwIfdoclNZkqK5yInEZtc5ijKr0IPRgch79f35WP82C SNHVYApmjzgwggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoT EVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERp dmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG 9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcN MDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmlj YXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNE KYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu 2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQAB o04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0T AQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0 S1liiu1EvknH6A27j7kNaiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHC CafvS65y3QZn9VBvLli4tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+p lrgFPFL83eliA0gxggHdMIIB2QIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNV BAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMFMYswCQYFKw4DAhoFAKCBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMTA5MDYwMjM0MjVaMCMGCSqGSIb3DQEJBDEWBBT3zuXX 8OhbLwaIJleuznqT97ADZDA6BgkqhkiG9w0BCQ8xLTArMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBgkqhkiG9w0BAQEFAASBgM/CbZ0QuTB6fwGx7RxV WvRW4W1R5lr4NwFb5rZw4dc9mnynBE45KY58tfnAcsNjmZBCRQNOMkWRkNQHeEJ4bEL5EU+S D3d0Q77qdeBW7ghH7CiTxYnCi2EmeWeJHniiFJ956ILexcjsBIH9IIYcyjfRJTleq2AtlC22 kODjeK2J --------------ms9D010F1D9EE124DC7B2A3473-- From owner-linux-xfs@oss.sgi.com Thu Sep 6 07:34:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86EYv518189 for linux-xfs-outgoing; Thu, 6 Sep 2001 07:34:57 -0700 Received: from atrey.karlin.mff.cuni.cz (root@atrey.karlin.mff.cuni.cz [195.113.31.123]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86EYnd18168 for ; Thu, 6 Sep 2001 07:34:49 -0700 Received: (from jack@localhost) by atrey.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) id QAA29808; Thu, 6 Sep 2001 16:34:42 +0200 Date: Thu, 6 Sep 2001 16:34:41 +0200 From: Jan Kara To: Nathan Scott Cc: "'linux-xfs@oss.sgi.com'" , samba-technical@lists.samba.org Subject: Re: XFS, Quotas and Samba Message-ID: <20010906163441.C24754@atrey.karlin.mff.cuni.cz> References: <7AC902A40BEDD411A3A800D0B7847B660882F5@sernt14.essex.ac.uk> <20010906105952.B345981@wobbly.melbourne.sgi.com> <20010906123515.A380241@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <20010906123515.A380241@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Thu, Sep 06, 2001 at 12:35:15PM +1100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, Actually it depends whether the samba code was compiled with proper kernel headers. If so the Q_GETQUOTA is defined to be right value and so everything should work fine. Ok, to be more precise the utils probably won't compile in that case as struct dqblk is no more and mem_dqblk should be used instead... But anyway it shouldn't break silently. Honza > Just a quick followup - this is what I mentioned in my earlier > mail to you. I think your new VFS quota code (as in Alan Cox's > series of 2.4 kernels, for the Samba folk) will have exactly the > same problem as XFS. This "grep" would seem to confirm it - but > you'll know better than I here: > > 11:31 nathans@troppo ~/cvs/quota-tools 73> grep GETQUOTA dqblk*h > dqblk_rpc.h:#define Q_RPC_GETQUOTA 0x0300 /* get limits and usage */ > dqblk_v1.h:#define Q_V1_GETQUOTA 0x300 > dqblk_v2.h:#define Q_V2_GETQUOTA 0x0D00 /* Get limits and usage */ > dqblk_xfs.h:#define Q_XFS_GETQUOTA Q_XGETQUOTA > 11:31 nathans@troppo ~/cvs/quota-tools 74> > > The samba code does a good old Q_GETQUOTA (ie. your V1 above). > > cheers. > > > On Thu, Sep 06, 2001 at 10:59:52AM +1100, Nathan Scott wrote: > > hi, > > > > On Wed, Sep 05, 2001 at 02:57:39PM +0100, Giddings, Bret wrote: > > > I am investigating whether I can replace my expensive Compaq Alphas file > > > servers with cheaper (and invariably faster given my budget) Intel based > > > ones. I have so far been pleased with the ease with which xfs has installed > > > and run on my hardware of choice. To make my life easier, I have picked up > > > the pre-built RedHat kernels with xfs support. Everything appears to be fine > > > except that when connecting to a share from Samba, the amount of free space > > > reported is the amount of free disk space left on the device rather than the > > > amount of free space in the users quota (this is on a disk mounted with > > > usrquota and a quota set for the users). The usual tools (edquota, setquota > > > work as expected). > > > > > > I have downloaded the source rpm for samba and it appears that RedHat build > > > their smbd to support quotas. I have also checked whether > > > /usr/include/sys/quota.h is modified by installing your updated quota rpm > > > (quota-3.01pre8) and it isn't. So, is there another reason why quotas don't > > > appear to work with xfs/samba? > > > > The samba code needs to be updated to support XFS quota under > > Linux. There was someone on the list a little while ago who > > was looking to add in the samba support for XFS quota, but I > > don't know how far they got. > > > > I know very little about samba unfortunately, but it should be > > quite simple to add this stuff for XFS - the disk_quotas() > > routine in samba-2.2.1a/source/smbd/quotas.c is all that needs > > to be changed, by the look of things. > > > > For XFS filesystems on Linux this needs to: > > - have logic to handle getmntent's of type "xfs" separately; > > - issue a quotactl(QCMD(Q_XGETQUOTA,USRQUOTA), ..., &xdq) where > > xdq is of type "struct fs_disk_quota_t" from > > - set *bsize to 512 for XFS > > - refer to the code later in that same file for dealing with XFS > > on IRIX - basically, do exactly the same thing and it should > > just work. > > - to do it properly, the configure scripts will need to check > > for linux/xqm.h (or might be simpler to keep a local copy? - > > I dunno what sort of policy the samba folk have on this sort of > > thing, but this header isn't going to change and probably isn't > > going to appear in the libc headers for quite awhile...) > > > > cheers. > > > > -- > > Nathan > > -- > Nathan -- Jan Kara SuSE Labs From owner-linux-xfs@oss.sgi.com Thu Sep 6 11:31:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86IVwG21933 for linux-xfs-outgoing; Thu, 6 Sep 2001 11:31:58 -0700 Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86IVtd21914 for ; Thu, 6 Sep 2001 11:31:55 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA77674 for ; Thu, 6 Sep 2001 14:29:38 -0400 Received: from d03nm080.boulder.ibm.com (d03nm080.boulder.ibm.com [9.99.140.64]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f86IV6t130852 for ; Thu, 6 Sep 2001 12:31:06 -0600 Subject: GPL and DMAPI To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "James A Goodwin" Date: Thu, 6 Sep 2001 13:31:03 -0500 X-MIMETrack: Serialize by Router on D03NM080/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/06/2001 12:31:06 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The GPL indicates that linking with libraries distributed under it results in an executable which is also under GPL. This means that any client program written as a client to the Linux XFS DMAPI library is sucked in under GPL, even though no GPL code was modified. Was this SGI's intent? If so, it seems to effectively destroy any chance of commercial software interfacing with Linux XFS, via DMAPI or any other supplied library. If not, is there any plan to distribute Linux XFS under the LGPL, which does allow non-GPL linking? Thanks, -James Goodwin Software Engineer IBM Global Services - Federal From owner-linux-xfs@oss.sgi.com Thu Sep 6 11:43:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86Ihah22307 for linux-xfs-outgoing; Thu, 6 Sep 2001 11:43:36 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86IhXd22288 for ; Thu, 6 Sep 2001 11:43:34 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 343DA1E57C; Thu, 6 Sep 2001 20:43:28 +0200 (MEST) Date: Thu, 6 Sep 2001 20:43:21 +0200 From: Andi Kleen To: Steve Lord Cc: Federico Sevilla III , Dan Yocum , Linux XFS Mailing List , "Philippine Linux Users' Group Mailing List" Subject: Re: On RAID, inode size, stripe size (was: Playing around with NFS+XFS) Message-ID: <20010906204321.A11973@gruyere.muc.suse.de> References: <200109051536.f85FaOO05864@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200109051536.f85FaOO05864@jen.americas.sgi.com>; from lord@sgi.com on Wed, Sep 05, 2001 at 10:36:24AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Sep 05, 2001 at 10:36:24AM -0500, Steve Lord wrote: > This is not a raid5 thing, it is a filesystem size issue, once you get > above 1 Tbyte in filesystem size then xfs inode numbers (which are really > a disk address) can take more than 32 bits. Since lots of linux code, > including NFS, does not cope with this, we need to change things in xfs Since 2.4.5 or so mainstream 2.4 has the fh_to_dentry/dentry_to_fh super block interfaces. They are currently only used by reiserfs to handle their equivalent of 64bit inodes; but XFS could use them too to at least avoid problems with NFS for the big file systems. -Andi From owner-linux-xfs@oss.sgi.com Thu Sep 6 11:56:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86IuBw22716 for linux-xfs-outgoing; Thu, 6 Sep 2001 11:56:11 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86Iu8d22692 for ; Thu, 6 Sep 2001 11:56:08 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA06542 for ; Thu, 6 Sep 2001 11:54:33 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2866037; Thu, 6 Sep 2001 13:53:35 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA69978; Thu, 6 Sep 2001 13:53:34 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f86Ip7V14446; Thu, 6 Sep 2001 13:51:07 -0500 Message-Id: <200109061851.f86Ip7V14446@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andi Kleen cc: Steve Lord , Federico Sevilla III , Dan Yocum , Linux XFS Mailing List , "Philippine Linux Users' Group Mailing List" Subject: Re: On RAID, inode size, stripe size (was: Playing around with NFS+XFS) In-Reply-To: Message from Andi Kleen of "Thu, 06 Sep 2001 20:43:21 +0200." <20010906204321.A11973@gruyere.muc.suse.de> Date: Thu, 06 Sep 2001 13:51:06 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Wed, Sep 05, 2001 at 10:36:24AM -0500, Steve Lord wrote: > > This is not a raid5 thing, it is a filesystem size issue, once you get > > above 1 Tbyte in filesystem size then xfs inode numbers (which are really > > a disk address) can take more than 32 bits. Since lots of linux code, > > including NFS, does not cope with this, we need to change things in xfs > > Since 2.4.5 or so mainstream 2.4 has the fh_to_dentry/dentry_to_fh super > block interfaces. They are currently only used by reiserfs to handle > their equivalent of 64bit inodes; but XFS could use them too to at least > avoid problems with NFS for the big file systems. > > -Andi Hmm, it does not solve the problem of stat calls etc which return a 32 bit inode to user space. We also have an application issue with XFS on Irix which means we need to do the solution where we force inodes into 32 bits by placement within the filesystem. Steve From owner-linux-xfs@oss.sgi.com Thu Sep 6 12:08:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86J8jV23215 for linux-xfs-outgoing; Thu, 6 Sep 2001 12:08:45 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86J8gd23196 for ; Thu, 6 Sep 2001 12:08:42 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA05450 for ; Thu, 6 Sep 2001 12:07:07 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2898046; Thu, 6 Sep 2001 14:07:25 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA77452; Thu, 6 Sep 2001 14:07:25 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f86J4vl14613; Thu, 6 Sep 2001 14:04:57 -0500 Message-Id: <200109061904.f86J4vl14613@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "James A Goodwin" cc: linux-xfs@oss.sgi.com Subject: Re: GPL and DMAPI In-Reply-To: Message from "James A Goodwin" of "Thu, 06 Sep 2001 13:31:03 CDT." Date: Thu, 06 Sep 2001 14:04:57 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > The GPL indicates that linking with libraries distributed under it results > in an executable which is also under GPL. This means that any client > program written as a client to the Linux XFS DMAPI library is sucked in > under GPL, even though no GPL code was modified. > > Was this SGI's intent? If so, it seems to effectively destroy any chance > of commercial software interfacing with Linux XFS, via DMAPI or any other > supplied library. > > If not, is there any plan to distribute Linux XFS under the LGPL, which > does allow non-GPL linking? > We will have to think about this one I guess, but how much of a cut can SGI get from IBM if you start selling something ;-). No seriously you have a good point. Steve > Thanks, > > -James Goodwin > Software Engineer > IBM Global Services - Federal From owner-linux-xfs@oss.sgi.com Thu Sep 6 12:12:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86JCff23439 for linux-xfs-outgoing; Thu, 6 Sep 2001 12:12:41 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86JCcd23412 for ; Thu, 6 Sep 2001 12:12:38 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 7BAF71E57B; Thu, 6 Sep 2001 21:12:32 +0200 (MEST) Date: Thu, 6 Sep 2001 21:12:31 +0200 From: Andi Kleen To: Steve Lord Cc: Andi Kleen , Federico Sevilla III , Dan Yocum , Linux XFS Mailing List , "Philippine Linux Users' Group Mailing List" Subject: Re: On RAID, inode size, stripe size (was: Playing around with NFS+XFS) Message-ID: <20010906211231.B12207@gruyere.muc.suse.de> References: <200109061851.f86Ip7V14446@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200109061851.f86Ip7V14446@jen.americas.sgi.com>; from lord@sgi.com on Thu, Sep 06, 2001 at 01:51:06PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Sep 06, 2001 at 01:51:06PM -0500, Steve Lord wrote: > > On Wed, Sep 05, 2001 at 10:36:24AM -0500, Steve Lord wrote: > > > This is not a raid5 thing, it is a filesystem size issue, once you get > > > above 1 Tbyte in filesystem size then xfs inode numbers (which are really > > > a disk address) can take more than 32 bits. Since lots of linux code, > > > including NFS, does not cope with this, we need to change things in xfs > > > > Since 2.4.5 or so mainstream 2.4 has the fh_to_dentry/dentry_to_fh super > > block interfaces. They are currently only used by reiserfs to handle > > their equivalent of 64bit inodes; but XFS could use them too to at least > > avoid problems with NFS for the big file systems. > > > > -Andi > > Hmm, it does not solve the problem of stat calls etc which return a 32 > bit inode to user space. We also have an application issue with XFS on > Irix which means we need to do the solution where we force inodes into > 32 bits by placement within the filesystem. It requires LFS aware applications yes and for those a glibc change, but luckily no recompile. [I guess as soon as 2.5 started a new stat syscall should be reserved for that] If you have a nice way to make the lower 32bit of your inodes unique that would be of course more compatible. I just wanted to point out that it is not required for NFS. -Andi From owner-linux-xfs@oss.sgi.com Thu Sep 6 12:31:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86JVh623886 for linux-xfs-outgoing; Thu, 6 Sep 2001 12:31:43 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86JVed23867 for ; Thu, 6 Sep 2001 12:31:40 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f86JVX521705 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 6 Sep 2001 12:31:33 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA73743 for ; Thu, 6 Sep 2001 21:31:36 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2906527; Thu, 6 Sep 2001 14:30:13 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA95822; Thu, 6 Sep 2001 14:30:13 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f86JRj914879; Thu, 6 Sep 2001 14:27:45 -0500 Message-Id: <200109061927.f86JRj914879@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "James A Goodwin" cc: linux-xfs@oss.sgi.com Subject: Re: GPL and DMAPI In-Reply-To: Message from "James A Goodwin" of "Thu, 06 Sep 2001 13:31:03 CDT." Date: Thu, 06 Sep 2001 14:27:45 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > The GPL indicates that linking with libraries distributed under it results > in an executable which is also under GPL. This means that any client > program written as a client to the Linux XFS DMAPI library is sucked in > under GPL, even though no GPL code was modified. > > Was this SGI's intent? If so, it seems to effectively destroy any chance > of commercial software interfacing with Linux XFS, via DMAPI or any other > supplied library. > > If not, is there any plan to distribute Linux XFS under the LGPL, which > does allow non-GPL linking? As James found out, the dmapi library is actually already LGPL. so there is no constraint on using it. Steve From owner-linux-xfs@oss.sgi.com Thu Sep 6 12:34:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86JYkr24025 for linux-xfs-outgoing; Thu, 6 Sep 2001 12:34:46 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86JYid24006 for ; Thu, 6 Sep 2001 12:34:44 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f86JYc522016 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 6 Sep 2001 12:34:38 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA73685 for ; Thu, 6 Sep 2001 21:34:40 +0200 (CEST) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2883044; Thu, 6 Sep 2001 14:33:16 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA44218; Thu, 6 Sep 2001 14:33:16 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id OAA73113; Thu, 6 Sep 2001 14:33:15 -0500 (CDT) Message-Id: <200109061933.OAA73113@slobber.americas.sgi.com> To: "James A Goodwin" cc: kenmcd@sgi.com, linux-xfs@oss.sgi.com Subject: Re: GPL and DMAPI Date: Thu, 06 Sep 2001 14:33:15 -0500 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "James A Goodwin" >The GPL indicates that linking with libraries distributed under it results >in an executable which is also under GPL. This means that any client >program written as a client to the Linux XFS DMAPI library is sucked in >under GPL, even though no GPL code was modified. > >Was this SGI's intent? If so, it seems to effectively destroy any chance >of commercial software interfacing with Linux XFS, via DMAPI or any other >supplied library. > >If not, is there any plan to distribute Linux XFS under the LGPL, which >does allow non-GPL linking? Maybe we just need to change the relevant libraries to be LGPL? This would include all of cmd/dmapi and all of cmd/xfsprogs/libhandle. Do we also need to change the license on any header files used when building these libraries? Ken, do we have an LGPL comment block to put in place of the GPL comment block on these files? Do I just change all instances of "General Public License" with "Lesser General Public License"? And change the license version from 2 to 2.1? Dean From owner-linux-xfs@oss.sgi.com Thu Sep 6 12:44:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86Jisr24436 for linux-xfs-outgoing; Thu, 6 Sep 2001 12:44:54 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86Jiqd24417 for ; Thu, 6 Sep 2001 12:44:52 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f86Jik522722 for ; Thu, 6 Sep 2001 12:44:46 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2906481; Thu, 6 Sep 2001 14:43:31 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA21614; Thu, 6 Sep 2001 14:43:30 -0500 (CDT) Message-ID: <3B97D17A.E7E3228D@sgi.com> Date: Thu, 06 Sep 2001 14:41:46 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: James A Goodwin , linux-xfs@oss.sgi.com Subject: Re: GPL and DMAPI References: <200109061927.f86JRj914879@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > As James found out, the dmapi library is actually already LGPL. so there > is no constraint on using it. That's what cmd/dmapi/doc/COPYING says, but the headers in the individual files say otherwise - I guess we need to sync that up. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Sep 6 12:54:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86Js6c24705 for linux-xfs-outgoing; Thu, 6 Sep 2001 12:54:06 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86Js4d24686 for ; Thu, 6 Sep 2001 12:54:04 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f86Jrw523365 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Thu, 6 Sep 2001 12:53:58 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA74316 for ; Thu, 6 Sep 2001 21:54:01 +0200 (CEST) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2892102; Thu, 6 Sep 2001 14:52:34 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA48330; Thu, 6 Sep 2001 14:52:34 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id OAA64576; Thu, 6 Sep 2001 14:52:33 -0500 (CDT) Message-Id: <200109061952.OAA64576@slobber.americas.sgi.com> To: Eric Sandeen cc: Steve Lord , James A Goodwin , linux-xfs@oss.sgi.com Subject: Re: GPL and DMAPI Date: Thu, 06 Sep 2001 14:52:33 -0500 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: Eric Sandeen >Steve Lord wrote: > >> As James found out, the dmapi library is actually already LGPL. so there >> is no constraint on using it. > >That's what cmd/dmapi/doc/COPYING says, but the headers in the >individual files say otherwise - I guess we need to sync that up. Ah, thank you. So, I can modify the license comment block in each file under cmd/dmapi. Now, what do we do with libhandle? This is used by libdm. The cmd/xfsprogs/doc/COPYING file does not mention the LGPL. Dean From owner-linux-xfs@oss.sgi.com Thu Sep 6 13:27:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86KRrj25829 for linux-xfs-outgoing; Thu, 6 Sep 2001 13:27:53 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86KRod25810 for ; Thu, 6 Sep 2001 13:27:50 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA07989 for ; Thu, 6 Sep 2001 13:26:15 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2897973 for ; Thu, 6 Sep 2001 15:26:33 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA11573 for ; Thu, 6 Sep 2001 15:26:33 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f86KO5415202; Thu, 6 Sep 2001 15:24:05 -0500 Message-Id: <200109062024.f86KO5415202@jen.americas.sgi.com> Date: Thu, 6 Sep 2001 15:24:05 -0500 Subject: TAKE - fix mongo_pl hangs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We may be falling victim to the 'page aging does not work' thread on linux-kernel in that we appear to be having very recently used blocks pulled out from under us. However, there is a problem with XFS getting called in the non-transaction case. If we end up in page_launder() and call back into XFS which does a transaction which ends up needing to flush the log there is a deadlock. This actually pulls us back more in line with the way things work on Irix. Date: Thu Sep 6 12:52:37 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102267a linux/fs/xfs/xfs_trans_buf.c - 1.96 - Add in BUF_BUSY flag into the non-transaction cases in trans_get_buf and trans_read_buf to avoid deadlocks where we come back into the filesystem again via page_launder. From owner-linux-xfs@oss.sgi.com Thu Sep 6 15:28:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86MSN928489 for linux-xfs-outgoing; Thu, 6 Sep 2001 15:28:23 -0700 Received: from mfive.engr.matrixsemi.com ([64.3.134.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86MSJd28467 for ; Thu, 6 Sep 2001 15:28:21 -0700 Received: from matrixsemi.com (mfive.engr.matrixsemi.com [192.168.128.51]) by mfive.engr.matrixsemi.com (Postfix) with ESMTP id 06221B15ABE for ; Thu, 6 Sep 2001 15:30:05 -0700 (PDT) Message-ID: <3B97F8ED.11008423@matrixsemi.com> Date: Thu, 06 Sep 2001 15:30:05 -0700 From: Shiv Sikand Organization: Matrix Semiconductor X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS Rules Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk XFS People, We have 10+ machines running 2.4.5-xfs-1.0.1 on ATA-100 drives here at Matrix. We install using the Mandrake 8 Cooker XFS CD's that we downloaded and burnt. It's been about 3 months now and we now have 200+ GIGS of data on XFS. Not a single problem, brilliant performance. Awesome stuff people. Please don't stop. Cheers, Shiv From owner-linux-xfs@oss.sgi.com Thu Sep 6 16:41:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f86NfC229903 for linux-xfs-outgoing; Thu, 6 Sep 2001 16:41:12 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f86Nf9d29884 for ; Thu, 6 Sep 2001 16:41:09 -0700 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f86Nf3508208 for ; Thu, 6 Sep 2001 16:41:03 -0700 Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA54994 for ; Thu, 6 Sep 2001 16:46:10 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id DAEE715A213 for ; Thu, 6 Sep 2001 16:39:42 -0700 (PDT) Subject: Re: kernel spam when mounting xfs From: Florin Andrei To: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 06 Sep 2001 16:39:42 -0700 Message-Id: <999819582.7485.106.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 05 Sep 2001 20:53:19 +0800, Federico Sevilla III wrote: > > I made a small talk for the local Linux10 celebrations. If you're > interested you can go to > to take a look at > my slides. Just to point out a small thing: in your presentation, you say "full data journalling offers a severe performance impact, effectively halfing write performance". Well, this may or may not be true. In fact, for some workloads, Ext3 is faster than Ext2 even with full data journalling turned on: http://marc.theaimsgroup.com/?l=postfix-users&m=99654359818329&w=2 - full-journalling ext3 can offer a 3x to 10x improvement over ext2, depending upon how ext2 is used and the directory layout/task count (it's actually Postfix having its mail spool directory on Ext2/3, and it seems to be true only for such usage patterns as with MTAs) Thanks to ppetru@ppetru.net for pointing out this link. But, anyway, your presentation is great. ;-) -- Florin Andrei "Our kernel does have source control: its name is Linus Torvalds, CVS with a brain." - Nicholas Knight From owner-linux-xfs@oss.sgi.com Thu Sep 6 22:09:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8759r102637 for linux-xfs-outgoing; Thu, 6 Sep 2001 22:09:53 -0700 Received: from mailhost.mil.ameritech.net (mpdr0.milwaukee.wi.ameritech.net [206.141.239.126]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8759nd02618 for ; Thu, 6 Sep 2001 22:09:50 -0700 Received: from there ([64.108.133.55]) by mailhost.mil.ameritech.net (InterMail v4.01.01.07 201-229-111-110) with SMTP id <20010907050943.DBDK10497.mailhost.mil.ameritech.net@there>; Fri, 7 Sep 2001 00:09:43 -0500 Content-Type: text/plain; charset="iso-8859-1" From: James To: linux-xfs@oss.sgi.com Subject: Are there any issues with Sparcstations Date: Fri, 7 Sep 2001 00:04:58 -0500 X-Mailer: KMail [version 1.3] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20010907050943.DBDK10497.mailhost.mil.ameritech.net@there> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi I am happily running XFS on my main home file server (intel), and am thinking about using XFS on my new ( for me, anyway) Sparcstation 5, it will be a couple of small partitions less than 5gig each, that will house a small news feed, is XFS (cvs) ready/compatible with Sparc's running Linux ? Thanks for the input, and keep up the good work, James linux-xfs 2.4.9 : uptime 12 days 12 hours From owner-linux-xfs@oss.sgi.com Fri Sep 7 01:11:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f878BHM05458 for linux-xfs-outgoing; Fri, 7 Sep 2001 01:11:17 -0700 Received: from gateway1.brets.elevating.com (adsl-216-63-236-137.dsl.tulsok.swbell.net [216.63.236.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f878BDd05437 for ; Fri, 7 Sep 2001 01:11:13 -0700 Received: from elevating.com (bretdell.brets.elevating.com [192.168.0.128]) by gateway1.brets.elevating.com (8.9.3/8.8.7) with ESMTP id DAA29336; Fri, 7 Sep 2001 03:11:02 -0500 Message-ID: <3B988116.E31FAF1C@elevating.com> Date: Fri, 07 Sep 2001 03:11:02 -0500 From: Bret Hughes X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en, ja MIME-Version: 1.0 To: linux-xfs Subject: compaq smart 2 raid and XFS 1.0.1 redhat install problems Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I give up. I have totally hosed a compaq 3000 machine that was working perfectly under rh6.2. fortunately it is not our main production box but I still need to get this thing up and running. First I tried an upgrade that appeared to be fine but lilo and I got confused ( at least I was ) I told the installer to use the MBR and that is where compaq utilities stuff gets started from. It was still booting the 2.2.3-16 kernel. Very weird. I putzed with it for too long trying different iterations of upgrades (both XFS and regular redhat 7.1) trying to figure out what was happening. My partner found the deal about compaq needing the mbr so I did the old dos diskette and fdisk /mbr. This let me boot to the right kernel but the system hung right after the compaq smart 2 initialization and gave the message checking partitions: and a reference to using ida/c0d0 I figured I had screwed up the packages so I did an install (not an upgrade ) to an unused partition and get the same error. I have worn out my mouse and me searching the mailing list archives for references to what might be happening. I tried various things like linux devfs=nomount at the lilo prompt. No joy. Are ther issues with the Compaq smart-2 raid controllers and XFS? I see that there is some patching that went on but in reference to it but I could not tell exactly what the issues are. do I need to do the CVS deal and compile my own kernel? How do I get it onto a machine that I cannot boot? Please help. I am fried. Bret From owner-linux-xfs@oss.sgi.com Fri Sep 7 01:36:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f878akk05903 for linux-xfs-outgoing; Fri, 7 Sep 2001 01:36:46 -0700 Received: from alaska.net (sephiroth.nwc.alaska.net [209.112.130.27]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f878aed05884 for ; Fri, 7 Sep 2001 01:36:41 -0700 Received: from erbenson.alaska.net (198-pm16.nwc.alaska.net [209.112.141.198]) by alaska.net (8.11.5/8.11.5) with ESMTP id f878acP11513 for ; Fri, 7 Sep 2001 00:36:38 -0800 (AKDT) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id DFC49397B for ; Fri, 7 Sep 2001 00:36:36 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 1404710246; Fri, 7 Sep 2001 00:36:37 -0800 (AKDT) Date: Fri, 7 Sep 2001 00:36:37 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Are there any issues with Sparcstations Message-ID: <20010907003636.F23184@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20010907050943.DBDK10497.mailhost.mil.ameritech.net@there> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iVCmgExH7+hIHJ1A" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010907050943.DBDK10497.mailhost.mil.ameritech.net@there>; from jdickens@ameritech.net on Fri, Sep 07, 2001 at 12:04:58AM -0500 X-OS: Debian GNU Mail-Copies-To: nobody Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --iVCmgExH7+hIHJ1A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 07, 2001 at 12:04:58AM -0500, James wrote: >=20 > Hi=20 >=20 > I am happily running XFS on my main home file server (intel), and am thin= king=20 > about using XFS on my new ( for me, anyway) Sparcstation 5, it will be a= =20 > couple of small partitions less than 5gig each, that will house a small n= ews=20 > feed, is XFS (cvs) ready/compatible with Sparc's running Linux ? one problem i can think of is the way sparcs are partitioned and how the bootloader (silo) works... correct me if im wrong anywhere i don't own a sparc and have only done a couple installs (plain ext2) on them. in all the install docs ive read your told to create the first partition (the root partition) starting at cylinder 0, this has the affect of the partition table (which is also at cylinder 0) being ON the root partition, this normally isn't a problem since with ext2 the first 2 blocks are unused to make room for bootloaders generally. =20 so from what i can tell the partition table is on the first 512 byte block, and the silo first stage goes in the second 512 byte block, ext2 doesn't care since that 1k is its unused space for bootloaders. =20 XFS however has no such space, its superblock (or something) starts right at the very start of the partition, so if you partition the way all the docs say to and intend to make your root partition XFS the partition table will be destroyed the moment you create the XFS filesystem. =20 an obvious (to me) solution would simply be don't create the first partition on cylinder 0, but i imagine there is some reason why all the docs say to do that (something to do with silo?) someone with more knowledge of sparcs would have to comment, but it seems XFS on root is not possible on sparcs. silo would also be unable to read its configuration file since it currently doesn't support xfs. another possibility is putting a ext2 /boot partition first and then telling silo to read its config from there instead. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --iVCmgExH7+hIHJ1A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuYhxQACgkQJKx7GixEevwIuQCgjCTdwHMNHeWWuFvFY0tXMcSE Ou0An0T/epN96J5T1zdCoBeV7K4wk6Ae =jeWd -----END PGP SIGNATURE----- --iVCmgExH7+hIHJ1A-- From owner-linux-xfs@oss.sgi.com Fri Sep 7 01:38:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f878cQP06039 for linux-xfs-outgoing; Fri, 7 Sep 2001 01:38:26 -0700 Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.247.6.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f878bqd06014 for ; Fri, 7 Sep 2001 01:37:52 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id f878boQ04381 for ; Fri, 7 Sep 2001 17:37:50 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id f878bmI05582 for ; Fri, 7 Sep 2001 17:37:48 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id f878bhF18075 for ; Fri, 7 Sep 2001 17:37:45 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA493 for ; Fri, 7 Sep 2001 17:37:40 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Fri Sep 07 17:37:18 2001 +0900 Received: from rifu.bsd.tnes.nec.co.jp (IDENT:root@rifu.bsd.tnes.nec.co.jp [10.1.101.142]) by mailsv.tnes.nec.co.jp (8.9.3/3.7W01031510) with ESMTP id RAA14936 for ; Fri, 7 Sep 2001 17:37:17 +0900 (JST) Received: from tagajo.bsd.tnes.nec.co.jp (tagajo.bsd.tnes.nec.co.jp [10.1.101.146]) by rifu.bsd.tnes.nec.co.jp (8.10.2+3.3W/3.7W/BSD-TNES-MX01) with ESMTP id f878bGL08984 for ; Fri, 7 Sep 2001 17:37:17 +0900 Received: (from sasaki@localhost) by tagajo.bsd.tnes.nec.co.jp (8.8.5+2.7Wbeta5/3.5Wpl1-97090809) id RAA22356; Fri, 7 Sep 2001 17:37:15 +0900 (JST) Message-Id: <200109070837.RAA22356@tagajo.bsd.tnes.nec.co.jp> To: linux-xfs@oss.sgi.com Subject: xfsdump/xfsrestore failed sometimes when running QA suite 022 Date: Fri, 07 Sep 2001 17:37:15 +0900 From: Takayuki Sasaki Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have run QA suite ( cmd/xfstests/022 ) on my box, but sometimes it failed because the size or owner of a few files are mismatched before xfsdump / after xfsrestore. The error message is attached at the end of this mail. If I edit script 022 to erase a tape with writing an eof instead of erasing actually ( i.e. call _erase_soft instead of _erase_hard which are defined in cmd/xfstest/common.dump ), this issue never occured until now. Machine: Pentium III (Coppermine) 733MHz + SiS 630 chip set + 128MB RAM Tape: HP C1533A DDS2 SCSI Kernel: linux-2.4.10-pre1 with 20010829 CVS Tree xfsdump: 20010829 CVS Tree gcc: gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) This have been tested on kernel 2.4.8 and 2.4.9, but same issue occured... Why these files are destroyed? Are there any ideas? Thanks in advance. Taka root [108] > ./022 QA output created by 022 Put scsi tape driver into variable block size mode Creating directory system to dump using src/fsstress. ----------------------------------------------- fsstress : -f link=10 -f creat=10 -f mkdir=10 -f truncate=5 -f symlink=10 ----------------------------------------------- Erasing tape Dumping to tape... xfsdump -s DUMP_SUBDIR -f TAPE_DEV -M stress_tape_media -L stress_022 SCRATCH_MNT xfsdump: version 3.0 - Running single-threaded xfsdump: level 0 dump of HOSTNAME:SCRATCH_MNT xfsdump: dump date: DATE xfsdump: session id: ID xfsdump: session label: "stress_022" xfsdump: ino map phase 1: parsing subtree selections xfsdump: ino map phase 2: constructing initial dump list xfsdump: ino map phase 3: pruning unneeded subtrees xfsdump: ino map phase 4: estimating dump size xfsdump: ino map phase 5: skipping (only one dump stream) xfsdump: ino map construction complete xfsdump: estimated dump size: NUM bytes xfsdump: /var/xfsdump/inventory created xfsdump: preparing drive xfsdump: creating dump session media file 0 (media 0, file 0) xfsdump: dumping ino map xfsdump: dumping directories xfsdump: dumping non-directory files xfsdump: ending media file xfsdump: media file size NUM bytes xfsdump: dumping session inventory xfsdump: beginning inventory media file xfsdump: media file 1 (media 0, file 1) xfsdump: ending inventory media file xfsdump: inventory media file size NUM bytes xfsdump: writing stream terminator xfsdump: beginning media stream terminator xfsdump: media file 2 (media 0, file 2) xfsdump: ending media stream terminator xfsdump: media stream terminator size 1048576 bytes xfsdump: dump size (non-dir files) : NUM bytes xfsdump: dump complete: SECS seconds elapsed Rewinding tape Restoring from tape... xfsrestore -f TAPE_DEV -L stress_022 RESTORE_DIR xfsrestore: version 3.0 - Running single-threaded xfsrestore: using online session inventory xfsrestore: searching media for directory dump xfsrestore: preparing drive xfsrestore: examining media file 0 xfsrestore: reading directories xfsrestore: directory post-processing xfsrestore: restoring non-directory files xfsrestore: restore complete: SECS seconds elapsed Comparing listing of dump directory with restore directory *** TMP.dump_dir Wed Aug 29 17:24:12 2001 --- TMP.restore_dir Wed Aug 29 17:24:12 2001 *************** *** 13,24 **** drwxrwxrwx 2 root root 16 Aug 29 16:16 d39 drwxrwxrwx 5 root root 76 Aug 29 16:16 da drwxrwxrwx 4 root root 55 Aug 29 16:16 db ! -rw-rw-rw- 6 root root 551986 Aug 29 16:16 f21 -rw-rw-rw- 1 root root 712704 Aug 29 16:16 f47 -rw-rw-rw- 1 root root 0 Aug 29 16:16 f4f ! -rw-rw-rw- 6 root root 551986 Aug 29 16:16 f6 -rw-rw-rw- 3 root root 0 Aug 29 16:16 f61 ! -rw-rw-rw- 6 root root 551986 Aug 29 16:16 f7 lrwxrwxrwx 2 root root 939 Aug 29 DATE l29 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxx lrwxrwxrwx 2 root root 939 Aug 29 DATE l29 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxx lrwxrwxrwx 2 root root 939 Aug 29 DATE l36 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxx --- 13,24 ---- drwxrwxrwx 2 root root 16 Aug 29 16:16 d39 drwxrwxrwx 5 root root 76 Aug 29 16:16 da drwxrwxrwx 4 root root 55 Aug 29 16:16 db ! -rw-rw-rw- 6 root root 730637 Aug 29 16:16 f21 -rw-rw-rw- 1 root root 712704 Aug 29 16:16 f47 -rw-rw-rw- 1 root root 0 Aug 29 16:16 f4f ! -rw-rw-rw- 6 root root 730637 Aug 29 16:16 f6 -rw-rw-rw- 3 root root 0 Aug 29 16:16 f61 ! -rw-rw-rw- 6 root root 730637 Aug 29 16:16 f7 lrwxrwxrwx 2 root root 939 Aug 29 DATE l29 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxx lrwxrwxrwx 2 root root 939 Aug 29 DATE l29 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxx lrwxrwxrwx 2 root root 939 Aug 29 DATE l36 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxx *************** *** 31,37 **** /mnt/xfstest1/dump.1655/p0/d5/d2e: total TOTAL drwxrwxrwx 2 root root 26 Aug 29 16:16 d53 ! -rw-rw-rw- 1 root root 420819 Aug 29 16:16 f2f /mnt/xfstest1/dump.1655/p0/d5/d2e/d53: total TOTAL --- 31,37 ---- /mnt/xfstest1/dump.1655/p0/d5/d2e: total TOTAL drwxrwxrwx 2 root root 26 Aug 29 16:16 d53 ! -rw-rw-rw- 1 root root 0 Aug 29 16:16 f2f /mnt/xfstest1/dump.1655/p0/d5/d2e/d53: total TOTAL *************** *** 40,46 **** /mnt/xfstest1/dump.1655/p0/d5/d39: total TOTAL ! -rw-rw-rw- 6 root root 551986 Aug 29 16:16 f3e /mnt/xfstest1/dump.1655/p0/d5/da: total TOTAL --- 40,46 ---- /mnt/xfstest1/dump.1655/p0/d5/d39: total TOTAL ! -rw-rw-rw- 6 root root 730637 Aug 29 16:16 f3e /mnt/xfstest1/dump.1655/p0/d5/da: total TOTAL *************** *** 55,61 **** /mnt/xfstest1/dump.1655/p0/d5/da/d10: total TOTAL ! -rw-rw-rw- 2 root root 584907 Aug 29 16:16 f62 lrwxrwxrwx 6 root root 1018 Aug 29 DATE l25 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx lrwxrwxrwx 6 root root 1018 Aug 29 DATE l25 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx lrwxrwxrwx 1 root root 1011 Aug 29 DATE l5a -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxxx --- 55,61 ---- /mnt/xfstest1/dump.1655/p0/d5/da/d10: total TOTAL ! -rw-rw-rw- 2 root root 635646 Aug 29 16:16 f62 lrwxrwxrwx 6 root root 1018 Aug 29 DATE l25 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx lrwxrwxrwx 6 root root 1018 Aug 29 DATE l25 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx lrwxrwxrwx 1 root root 1011 Aug 29 DATE l5a -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxxx *************** *** 64,71 **** /mnt/xfstest1/dump.1655/p0/d5/da/d14: total TOTAL drwxrwxrwx 4 root root 56 Aug 29 16:16 d1f ! drwxrwxrwx 2 root root 36 Aug 29 16:16 d26 ! -rw-rw-rw- 3 root root 1906129 Aug 29 16:16 f55 /mnt/xfstest1/dump.1655/p0/d5/da/d14/d1f: total TOTAL --- 64,71 ---- /mnt/xfstest1/dump.1655/p0/d5/da/d14: total TOTAL drwxrwxrwx 4 root root 56 Aug 29 16:16 d1f ! drwxrwxrwx 2 root root 26 Aug 29 16:16 d26 ! -rw-rw-rw- 3 root root 956273 Aug 29 16:16 f55 /mnt/xfstest1/dump.1655/p0/d5/da/d14/d1f: total TOTAL *************** *** 95,101 **** /mnt/xfstest1/dump.1655/p0/d5/da/d14/d26: total TOTAL - -rw-rw-rw- 1 root root 0 Aug 29 16:16 f44 lrwxrwxrwx 2 root root 868 Aug 29 DATE l4e -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx lrwxrwxrwx 2 root root 868 Aug 29 DATE l4e -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx lrwxrwxrwx 1 root root 217 Aug 29 DATE l5e -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxx --- 95,100 ---- *************** *** 103,109 **** /mnt/xfstest1/dump.1655/p0/d5/da/d22: total TOTAL ! -rw-rw-rw- 6 root root 551986 Aug 29 16:16 f49 lrwxrwxrwx 1 root root 294 Aug 29 DATE l2c -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxx lrwxrwxrwx 1 root root 294 Aug 29 DATE l2c -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxx lrwxrwxrwx 1 root root 392 Aug 29 DATE l54 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/x --- 102,108 ---- /mnt/xfstest1/dump.1655/p0/d5/da/d22: total TOTAL ! -rw-rw-rw- 6 root root 730637 Aug 29 16:16 f49 lrwxrwxrwx 1 root root 294 Aug 29 DATE l2c -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxx lrwxrwxrwx 1 root root 294 Aug 29 DATE l2c -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxx lrwxrwxrwx 1 root root 392 Aug 29 DATE l54 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/x *************** *** 113,119 **** total TOTAL drwxrwxrwx 4 root root 46 Aug 29 16:16 d15 drwxrwxrwx 4 root root 44 Aug 29 16:16 dc ! -rw-rw-rw- 2 root root 1720320 Aug 29 16:16 f18 -rw-rw-rw- 1 root root 0 Aug 29 16:16 f67 lrwxrwxrwx 2 root root 868 Aug 29 DATE l20 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx lrwxrwxrwx 2 root root 868 Aug 29 DATE l20 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx --- 112,118 ---- total TOTAL drwxrwxrwx 4 root root 46 Aug 29 16:16 d15 drwxrwxrwx 4 root root 44 Aug 29 16:16 dc ! -rw-rw-rw- 2 root root 0 Aug 29 16:16 f18 -rw-rw-rw- 1 root root 0 Aug 29 16:16 f67 lrwxrwxrwx 2 root root 868 Aug 29 DATE l20 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx lrwxrwxrwx 2 root root 868 Aug 29 DATE l20 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx *************** *** 122,128 **** total TOTAL drwxrwxrwx 2 root root 6 Aug 29 16:16 d30 drwxrwxrwx 2 root root 16 Aug 29 16:16 d3a ! -rw-rw-rw- 3 root root 1906129 Aug 29 16:16 f1e lrwxrwxrwx 6 root root 1018 Aug 29 DATE l17 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx lrwxrwxrwx 6 root root 1018 Aug 29 DATE l17 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx --- 121,127 ---- total TOTAL drwxrwxrwx 2 root root 6 Aug 29 16:16 d30 drwxrwxrwx 2 root root 16 Aug 29 16:16 d3a ! -rw-rw-rw- 3 root root 956273 Aug 29 16:16 f1e lrwxrwxrwx 6 root root 1018 Aug 29 DATE l17 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx lrwxrwxrwx 6 root root 1018 Aug 29 DATE l17 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx *************** *** 131,144 **** /mnt/xfstest1/dump.1655/p0/d5/db/d15/d3a: total TOTAL ! -rw-rw-rw- 3 root root 1906129 Aug 29 16:16 f6e /mnt/xfstest1/dump.1655/p0/d5/db/dc: total TOTAL drwxrwxrwx 4 root root 46 Aug 29 16:16 d11 drwxrwxrwx 4 root root 36 Aug 29 16:16 d23 ! -rw-rw-rw- 6 root root 551986 Aug 29 16:16 fd ! -rw-rw-rw- 2 root root 584907 Aug 29 16:16 fe /mnt/xfstest1/dump.1655/p0/d5/db/dc/d11: total TOTAL --- 130,143 ---- /mnt/xfstest1/dump.1655/p0/d5/db/d15/d3a: total TOTAL ! -rw-rw-rw- 3 root root 956273 Aug 29 16:16 f6e /mnt/xfstest1/dump.1655/p0/d5/db/dc: total TOTAL drwxrwxrwx 4 root root 46 Aug 29 16:16 d11 drwxrwxrwx 4 root root 36 Aug 29 16:16 d23 ! -rw-rw-rw- 6 root root 730637 Aug 29 16:16 fd ! -rw-rw-rw- 2 root root 635646 Aug 29 16:16 fe /mnt/xfstest1/dump.1655/p0/d5/db/dc/d11: total TOTAL *************** *** 163,169 **** /mnt/xfstest1/dump.1655/p0/d5/db/dc/d11/d37: total TOTAL -rw-rw-rw- 1 root root 0 Aug 29 16:16 f4a ! -rw-rw-rw- 2 root root 1720320 Aug 29 16:16 f5c /mnt/xfstest1/dump.1655/p0/d5/db/dc/d23: total TOTAL --- 162,168 ---- /mnt/xfstest1/dump.1655/p0/d5/db/dc/d11/d37: total TOTAL -rw-rw-rw- 1 root root 0 Aug 29 16:16 f4a ! -rw-rw-rw- 2 root root 0 Aug 29 16:16 f5c /mnt/xfstest1/dump.1655/p0/d5/db/dc/d23: total TOTAL root [109] > From owner-linux-xfs@oss.sgi.com Fri Sep 7 01:52:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f878qUX06403 for linux-xfs-outgoing; Fri, 7 Sep 2001 01:52:30 -0700 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f878qRd06384 for ; Fri, 7 Sep 2001 01:52:27 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=jcb.mkp.net) by rover with esmtp (Exim 3.33 #1) id 15fHNB-00079K-00; Fri, 07 Sep 2001 04:52:26 -0400 Received: (from mkp@localhost) by jcb.mkp.net (8.11.2/8.9.3) id f878qPD14548; Fri, 7 Sep 2001 04:52:25 -0400 X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f To: James Cc: linux-xfs@oss.sgi.com Subject: Re: Are there any issues with Sparcstations References: <20010907050943.DBDK10497.mailhost.mil.ameritech.net@there> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 07 Sep 2001 04:52:25 -0400 In-Reply-To: <20010907050943.DBDK10497.mailhost.mil.ameritech.net@there> Message-ID: Lines: 18 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "James" == James writes: James> I am happily running XFS on my main home file server (intel), James> and am thinking about using XFS on my new ( for me, anyway) James> Sparcstation 5, it will be a couple of small partitions less James> than 5gig each, that will house a small news feed, is XFS (cvs) James> ready/compatible with Sparc's running Linux ? I haven't tried XFS on SPARC in a long time, so I don't know for sure. With a SPARCstation 5 you should be fine, though. On sun4u, on the other hand, we have a few issues with the userland utilities because kernel is 64-bit and userland is 32. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Fri Sep 7 02:18:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f879Ih807041 for linux-xfs-outgoing; Fri, 7 Sep 2001 02:18:43 -0700 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f879Idd07022 for ; Fri, 7 Sep 2001 02:18:40 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=jcb.mkp.net) by rover with esmtp (Exim 3.33 #1) id 15fHmY-0007Cr-00; Fri, 07 Sep 2001 05:18:38 -0400 Received: (from mkp@localhost) by jcb.mkp.net (8.11.2/8.9.3) id f879IbU14574; Fri, 7 Sep 2001 05:18:37 -0400 X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f To: Bret Hughes Cc: linux-xfs Subject: Re: compaq smart 2 raid and XFS 1.0.1 redhat install problems References: <3B988116.E31FAF1C@elevating.com> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 07 Sep 2001 05:18:37 -0400 In-Reply-To: <3B988116.E31FAF1C@elevating.com> Message-ID: Lines: 31 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Bret" == Bret Hughes writes: Bret> but the system hung right after the compaq smart 2 Bret> initialization and gave the message checking partitions: and a Bret> reference to using ida/c0d0 I've had several hangs at that exact spot with Smart RAIDs. In two of the cases it was bad hardware (bad DIMM and bad CPU respectively). Moved the bad DIMM to an identical box, and that would freeze too during Smart RAID init. And I've gotten into situations where all the Compaq BIOS/RAID/config goo would enter an inconsistent state. Windows would boot fine, but Linux would lock up at every attempt to grok the Smart RAID partitions. I solved that by booting the SmartStart CD and do a factory init of the box. Bret> Are ther issues with the Compaq smart-2 raid controllers and Bret> XFS? I'm going all my development on a box with a Compaq Smart-2. So XFS-specific issues, no. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Fri Sep 7 02:26:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f879QAa07370 for linux-xfs-outgoing; Fri, 7 Sep 2001 02:26:10 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f879Q7d07351 for ; Fri, 7 Sep 2001 02:26:07 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 87CF01E688; Fri, 7 Sep 2001 11:26:01 +0200 (MEST) Date: Fri, 7 Sep 2001 11:26:00 +0200 From: Andi Kleen To: "Martin K. Petersen" Cc: James , linux-xfs@oss.sgi.com Subject: Re: Are there any issues with Sparcstations Message-ID: <20010907112600.A23598@gruyere.muc.suse.de> References: <20010907050943.DBDK10497.mailhost.mil.ameritech.net@there> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mkp@linuxcare.com on Fri, Sep 07, 2001 at 04:52:25AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Sep 07, 2001 at 04:52:25AM -0400, Martin K. Petersen wrote: > >>>>> "James" == James writes: > > James> I am happily running XFS on my main home file server (intel), > James> and am thinking about using XFS on my new ( for me, anyway) > James> Sparcstation 5, it will be a couple of small partitions less > James> than 5gig each, that will house a small news feed, is XFS (cvs) > James> ready/compatible with Sparc's running Linux ? > > I haven't tried XFS on SPARC in a long time, so I don't know for sure. > With a SPARCstation 5 you should be fine, though. At least _pagebuf_free_lockable_buffer is clearly not sparc32 safe, because it gets save_flags flags arguments passed as an argument and will mess up the register window. So I doubt it'll work. -Andi From owner-linux-xfs@oss.sgi.com Fri Sep 7 02:32:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f879W7s07604 for linux-xfs-outgoing; Fri, 7 Sep 2001 02:32:07 -0700 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f879W3d07585 for ; Fri, 7 Sep 2001 02:32:03 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=jcb.mkp.net) by rover with esmtp (Exim 3.33 #1) id 15fHzW-0007EA-00; Fri, 07 Sep 2001 05:32:02 -0400 Received: (from mkp@localhost) by jcb.mkp.net (8.11.2/8.9.3) id f879W2t14583; Fri, 7 Sep 2001 05:32:02 -0400 X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f To: linux-xfs@oss.sgi.com Subject: Re: Are there any issues with Sparcstations References: <20010907050943.DBDK10497.mailhost.mil.ameritech.net@there> <20010907003636.F23184@plato.local.lan> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 07 Sep 2001 05:32:02 -0400 In-Reply-To: <20010907003636.F23184@plato.local.lan> Message-ID: Lines: 32 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Ethan" == Ethan Benson writes: Ethan> in all the install docs ive read your told to create the first Ethan> partition (the root partition) starting at cylinder 0, this has Ethan> the affect of the partition table (which is also at cylinder 0) Ethan> being ON the root partition, this normally isn't a problem Ethan> since with ext2 the first 2 blocks are unused to make room for Ethan> bootloaders generally. The issue here is that you shouldn't put neither swap, nor XFS on your first partition. None of them leave enough space at the beginning of the partition. Which partition root is on doesn't really matter. Make first partition start at cylinder 1, and Bob's your uncle (Having the third partition span the whole disk for Sun compatibility reasons isn't a problem, as long as you don't try to write your silo config to that slice). Ethan> silo would also be unable to read its configuration file since Ethan> it currently doesn't support xfs. another possibility is Ethan> putting a ext2 /boot partition first and then telling silo to Ethan> read its config from there instead. Yep. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Fri Sep 7 02:33:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f879XJp07822 for linux-xfs-outgoing; Fri, 7 Sep 2001 02:33:19 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f879X9d07792 for ; Fri, 7 Sep 2001 02:33:09 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id LAA18349; Fri, 7 Sep 2001 11:32:27 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id LAA03915; Fri, 7 Sep 2001 11:32:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id DF7AB57306; Fri, 7 Sep 2001 11:31:07 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 54A0325835; Fri, 7 Sep 2001 11:31:07 +0200 (CEST) Message-ID: <3B9893DB.F59296E@ch.sauter-bc.com> Date: Fri, 07 Sep 2001 11:31:07 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Bret Hughes Cc: linux-xfs Subject: Re: compaq smart 2 raid and XFS 1.0.1 redhat install problems References: <3B988116.E31FAF1C@elevating.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Bret Hughes schrieb: > > I give up. I have totally hosed a compaq 3000 machine that was working > perfectly under rh6.2. fortunately it is not our main production box > but I still need to get this thing up and running. > > First I tried an upgrade that appeared to be fine but lilo and I got > confused ( at least I was ) I told the installer to use the MBR and that > is where compaq utilities stuff gets started from. It was still booting > the 2.2.3-16 kernel. Very weird. I putzed with it for too long trying > different iterations of upgrades (both XFS and regular redhat 7.1) > trying to figure out what was happening. My partner found the deal > about compaq needing the mbr so I did the old dos diskette and fdisk > /mbr. This let me boot to the right kernel but the system hung right > after the compaq smart 2 initialization and gave the message checking > partitions: > and a reference to using ida/c0d0 > > I figured I had screwed up the packages so I did an install (not an > upgrade ) to an unused partition and get the same error. I have worn > out my mouse and me searching the mailing list archives for references > to what might be happening. I tried various things like linux > devfs=nomount at the lilo prompt. No joy. > > Are ther issues with the Compaq smart-2 raid controllers and XFS? I see > that there is some patching that went on but in reference to it but I > could not tell exactly what the issues are. do I need to do the CVS > deal and compile my own kernel? How do I get it onto a machine that I > cannot boot? Please help. I am fried. > > Bret To avoid problems sometimes you need to ged rid of all those special things on PC 'servers'. Usually I'm doing the following: - Zeroing the partitiontable, so getting rid of all those 'built in' tools. - Disable all kind of LBA (DOS 1G support) in the BIOS. Just put /boot in a small patition at beginning of the disk and you don't need any LBA. This has solved my problems on almost every PC 'server'. -Simon From owner-linux-xfs@oss.sgi.com Fri Sep 7 02:35:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f879ZFs07977 for linux-xfs-outgoing; Fri, 7 Sep 2001 02:35:15 -0700 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f879ZCd07958 for ; Fri, 7 Sep 2001 02:35:12 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=jcb.mkp.net) by rover with esmtp (Exim 3.33 #1) id 15fI2X-0007Eb-00; Fri, 07 Sep 2001 05:35:09 -0400 Received: (from mkp@localhost) by jcb.mkp.net (8.11.2/8.9.3) id f879Z8714586; Fri, 7 Sep 2001 05:35:08 -0400 X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f To: Andi Kleen Cc: James , linux-xfs@oss.sgi.com Subject: Re: Are there any issues with Sparcstations References: <20010907050943.DBDK10497.mailhost.mil.ameritech.net@there> <20010907112600.A23598@gruyere.muc.suse.de> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 07 Sep 2001 05:35:08 -0400 In-Reply-To: <20010907112600.A23598@gruyere.muc.suse.de> Message-ID: Lines: 17 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Andi" == Andi Kleen writes: >> I haven't tried XFS on SPARC in a long time, so I don't know for >> sure. With a SPARCstation 5 you should be fine, though. Andi> At least _pagebuf_free_lockable_buffer is clearly not sparc32 Andi> safe, because it gets save_flags flags arguments passed as an Andi> argument and will mess up the register window. So I doubt it'll Andi> work. Oh, right. I remember talking to DaveM about that. I've never actually tried XFS on sparc32... -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Fri Sep 7 06:21:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f87DL0w11796 for linux-xfs-outgoing; Fri, 7 Sep 2001 06:21:00 -0700 Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f87DKtd11777 for ; Fri, 7 Sep 2001 06:20:55 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA54442; Fri, 7 Sep 2001 09:18:39 -0400 Received: from d03nm080.boulder.ibm.com (d03nm080.boulder.ibm.com [9.99.140.64]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f87DKrb243778; Fri, 7 Sep 2001 07:20:53 -0600 Subject: Re: GPL and DMAPI To: Dean Roehrich Cc: Steve Lord , Eric Sandeen , linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "James A Goodwin" Date: Fri, 7 Sep 2001 08:20:51 -0500 X-MIMETrack: Serialize by Router on D03NM080/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/07/2001 07:20:53 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Are you saying that libdm.so is LGPL but libhandle.a is not? Since DMAPI applications don't directly utilize libhandle.a (it is utilized by the LGPL libdm.o) that doesn't make much sense. That would mean something like, "Here is this LGPL library to let your commercial applications use our code, but it has this dependency on a GPL library that makes you open source your software, ha ha!" What can be done to get the libhandle.a under LGPL? -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 Dean Roehrich com> cc: Steve Lord , James A Goodwin/Houston/IBM@IBMUS, linux-xfs@oss.sgi.com 09/06/2001 Subject: Re: GPL and DMAPI 02:52 PM >From: Eric Sandeen >Steve Lord wrote: > >> As James found out, the dmapi library is actually already LGPL. so there >> is no constraint on using it. > >That's what cmd/dmapi/doc/COPYING says, but the headers in the >individual files say otherwise - I guess we need to sync that up. Ah, thank you. So, I can modify the license comment block in each file under cmd/dmapi. Now, what do we do with libhandle? This is used by libdm. The cmd/xfsprogs/doc/COPYING file does not mention the LGPL. Dean From owner-linux-xfs@oss.sgi.com Fri Sep 7 07:22:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f87EM1d13060 for linux-xfs-outgoing; Fri, 7 Sep 2001 07:22:01 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f87ELwd13040 for ; Fri, 7 Sep 2001 07:21:58 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA01944 for ; Fri, 7 Sep 2001 07:20:23 -0700 (PDT) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2914211; Fri, 7 Sep 2001 09:19:25 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA64314; Fri, 7 Sep 2001 09:19:24 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id JAA73981; Fri, 7 Sep 2001 09:19:24 -0500 (CDT) Message-Id: <200109071419.JAA73981@slobber.americas.sgi.com> To: "James A Goodwin" cc: Steve Lord , Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: GPL and DMAPI Date: Fri, 07 Sep 2001 09:19:23 -0500 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "James A Goodwin" > >Are you saying that libdm.so is LGPL but libhandle.a is not? Since DMAPI >applications don't directly utilize libhandle.a (it is utilized by the LGPL >libdm.o) that doesn't make much sense. That would mean something like, >"Here is this LGPL library to let your commercial applications use our >code, but it has this dependency on a GPL library that makes you open >source your software, ha ha!" > >What can be done to get the libhandle.a under LGPL? We'll get it sorted out. Dean From owner-linux-xfs@oss.sgi.com Fri Sep 7 07:33:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f87EXqj13328 for linux-xfs-outgoing; Fri, 7 Sep 2001 07:33:52 -0700 Received: from k-7.stesmi.com (IDENT:root@as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f87EXnd13309 for ; Fri, 7 Sep 2001 07:33:49 -0700 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by k-7.stesmi.com (8.11.2/8.8.7) with ESMTP id f87Cvpc12888 for ; Fri, 7 Sep 2001 14:57:51 +0200 Message-ID: <3B98C3C0.3000706@stesmi.com> Date: Fri, 07 Sep 2001 14:55:28 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Preallocation of space References: <200109030908.f83988S26342@monkeyiq.dnsalias.org> <3B94F5D7.C4E4CD75@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi. >>I've found this page which I'll use as my reference to syssgi() >>unless there is a better online version. >>http://reality.sgi.com/cgi-bin/getman?syssgi-2#toc1 >> > > If you want to use it as a reference, save it locally... reality *might* > going away... :( No! If nothing more is real all we will have is surreality! I refuse it! I just got a new job so I like my reality! (Porting linux to an embedded application) Don't take it away from me! :) // Stefan From owner-linux-xfs@oss.sgi.com Fri Sep 7 09:37:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f87GboY15114 for linux-xfs-outgoing; Fri, 7 Sep 2001 09:37:50 -0700 Received: from bogon.blenke.com (653224hfc205.tampabay.rr.com [65.32.24.205]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f87Gbid15094 for ; Fri, 7 Sep 2001 09:37:44 -0700 Received: (from icblenke@localhost) by bogon.blenke.com (8.9.3/8.9.3/Debian 8.9.3-21) id MAA11157; Fri, 7 Sep 2001 12:37:28 -0400 From: "Ian C. Blenke" Date: Fri, 7 Sep 2001 12:37:28 -0400 To: Simon Matter Cc: Bret Hughes , linux-xfs Subject: Re: compaq smart 2 raid and XFS 1.0.1 redhat install problems Message-ID: <20010907123728.A10983@blenke.com> References: <3B988116.E31FAF1C@elevating.com> <3B9893DB.F59296E@ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B9893DB.F59296E@ch.sauter-bc.com> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Sep 07, 2001 at 11:31:07AM +0200, Simon Matter wrote: > > First I tried an upgrade that appeared to be fine but lilo and I got > > confused ( at least I was ) I told the installer to use the MBR and that > > is where compaq utilities stuff gets started from. It was still booting > > the 2.2.3-16 kernel. Very weird. I putzed with it for too long trying > > different iterations of upgrades (both XFS and regular redhat 7.1) > > trying to figure out what was happening. My partner found the deal > > about compaq needing the mbr so I did the old dos diskette and fdisk > > /mbr. This let me boot to the right kernel but the system hung right > > after the compaq smart 2 initialization and gave the message checking > > partitions: > > and a reference to using ida/c0d0 I'm using two 1850Rs with SmartArray2 controllers with no problems. Both are running Debian 2.2 (Potato) with handbuilt 2.4.6 XFS kernels, the CVS XFS cmd tools, and lvs 0.9.1_beta6 (all built from source). When building the servers, I used the SmartStart 4.70 (from memory) wipe, configured the RAID array, and installed the SmartStart partition. From there it took a little hand holding to get Potato on the system. I'm using grub (the older build from potato no less - what fun), not lilo. The biggest pain was getting lvm's vgscan to deal well with the /dev/ida/c0t0d2 style device naming (ended up with a symlink to /dev/sda devices to get it to act consistently). If you're using a I2O device, good luck (/dev/i2o/hda is even more obtuse). In the end, I ended up building everything as a module and hacked up /sbin/lvmcreate_initrd to include xfs/xfs_support/pagebuf, cpqarray, scsi_mod, aic7xxx, and sd_mod (the latter three for the onboard controller). Now I can build a new kernel, run lvmcreate_initrd, and avoid hand-building an initrd everytime. > > I figured I had screwed up the packages so I did an install (not an > > upgrade ) to an unused partition and get the same error. I have worn > > out my mouse and me searching the mailing list archives for references > > to what might be happening. I tried various things like linux > > devfs=nomount at the lilo prompt. No joy. I'll not get into religious debates about RedHat's RPM hell on this list ;) Been there. Done that. Burned the t-shirt. While I've built the CVS xfs cmd tools as DEBs, it's just not proper to pass them around ;) "Use the source". Keep it handy. > > Are ther issues with the Compaq smart-2 raid controllers and XFS? I see > > that there is some patching that went on but in reference to it but I > > could not tell exactly what the issues are. do I need to do the CVS > > deal and compile my own kernel? How do I get it onto a machine that I > > cannot boot? Please help. I am fried. None. I have two systems working wonderfully now: one with ~27GB (raid5), and the other with 54GB+44GB (raid5). No worries. You may *want* to build from CVS (I do, habitually now). I'm running two VA Linux boxen with XFS/LVM, and two Compaq 1850R boxen on SmartStart2 controllers with XFS/LVM, as well as a couple of happy XFS laptops. I've had incredibly few problems with XFS so far.. and lvextend/xfs_growfs really is a lifesaver. Good luck. - Ian C. Blenke From owner-linux-xfs@oss.sgi.com Fri Sep 7 12:04:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f87J4VA16941 for linux-xfs-outgoing; Fri, 7 Sep 2001 12:04:31 -0700 Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f87J4Sd16921 for ; Fri, 7 Sep 2001 12:04:28 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id 6CD6C139DC; Fri, 7 Sep 2001 15:04:25 -0400 (EDT) To: linux-xfs@oss.sgi.com Subject: fsck equivalent? Message-Id: <20010907190425.6CD6C139DC@linux.compucomis.net> Date: Fri, 7 Sep 2001 15:04:25 -0400 (EDT) From: mburger@compucomis.net (Mike Burger) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've got a drive that I think is flakey...but right now, it holds my /var file system. I've done some considerable customization (considering that the installation of the OS only occurred yesterday) and I'd hate to have to reinstall the whole damned OS, again. So, since the drive can't be mounted (error involves bad superblock), I'm in need of the name of a program I can run, manually, to check and repair the filesystem, if possible, so that I can then move the contents off to a replacement drive. Help? Thanks. --Mike PS: The system was installed using the latest SGI ISO installer and RH7.1 CDs. Thanks. From owner-linux-xfs@oss.sgi.com Fri Sep 7 12:10:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f87JA3v17123 for linux-xfs-outgoing; Fri, 7 Sep 2001 12:10:03 -0700 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f87JA0d17093 for ; Fri, 7 Sep 2001 12:10:00 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=jcb.mkp.net) by rover with esmtp (Exim 3.33 #1) id 15fR0p-000891-00; Fri, 07 Sep 2001 15:09:59 -0400 Received: (from mkp@localhost) by jcb.mkp.net (8.11.2/8.9.3) id f87J9w115237; Fri, 7 Sep 2001 15:09:58 -0400 X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f To: mburger@compucomis.net (Mike Burger) Cc: linux-xfs@oss.sgi.com Subject: Re: fsck equivalent? References: <20010907190425.6CD6C139DC@linux.compucomis.net> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 07 Sep 2001 15:09:58 -0400 In-Reply-To: <20010907190425.6CD6C139DC@linux.compucomis.net> Message-ID: Lines: 19 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Mike" == Mike Burger writes: Mike> I've got a drive that I think is flakey...but right now, it Mike> holds my /var file system. I've done some considerable Mike> customization (considering that the installation of the OS only Mike> occurred yesterday) and I'd hate to have to reinstall the whole Mike> damned OS, again. Mike> So, since the drive can't be mounted (error involves bad Mike> superblock), I'm in need of the name of a program I can run, Mike> manually, to check and repair the filesystem, if possible, so Mike> that I can then move the contents off to a replacement drive. xfs_repair -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Fri Sep 7 12:12:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f87JCEe17264 for linux-xfs-outgoing; Fri, 7 Sep 2001 12:12:14 -0700 Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f87JCBd17245 for ; Fri, 7 Sep 2001 12:12:12 -0700 Received: from tduffy-lnx.afara.com ([10.2.4.191]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 7 Sep 2001 12:07:44 -0700 Subject: Re: fsck equivalent? From: Thomas Duffy To: Mike Burger Cc: linux-xfs@oss.sgi.com In-Reply-To: <20010907190425.6CD6C139DC@linux.compucomis.net> References: <20010907190425.6CD6C139DC@linux.compucomis.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.13.99+cvs.2001.09.05.07.08 (Preview Release) Date: 07 Sep 2001 12:11:40 -0700 Message-Id: <999889901.8754.5.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 X-OriginalArrivalTime: 07 Sep 2001 19:07:44.0223 (UTC) FILETIME=[5FC006F0:01C137D0] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2001-09-07 at 12:04, Mike Burger wrote: > Help? xfs_repair -tduffy From owner-linux-xfs@oss.sgi.com Fri Sep 7 12:13:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f87JDxE17417 for linux-xfs-outgoing; Fri, 7 Sep 2001 12:13:59 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f87JDud17398 for ; Fri, 7 Sep 2001 12:13:56 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA07536 for ; Fri, 7 Sep 2001 12:12:21 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2914046; Fri, 7 Sep 2001 14:12:37 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA61879; Fri, 7 Sep 2001 14:12:37 -0500 (CDT) Message-ID: <3B991C24.9493F1C0@sgi.com> Date: Fri, 07 Sep 2001 14:12:36 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Mike Burger CC: linux-xfs@oss.sgi.com Subject: Re: fsck equivalent? References: <20010907190425.6CD6C139DC@linux.compucomis.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mike Burger wrote: > > I've got a drive that I think is flakey...but right now, it holds my > /var file system. I've done some considerable customization (considering > that the installation of the OS only occurred yesterday) and I'd hate to > have to reinstall the whole damned OS, again. > > So, since the drive can't be mounted (error involves bad superblock), I'm > in need of the name of a program I can run, manually, to check and repair > the filesystem, if possible, so that I can then move the contents off to > a replacement drive. You can try xfs_repair - the filesystem should be unmounted, and you can give it the "-n" option to see what it _would_ do, without actually doing anything. What sort of errors did you run into? (Just making sure it's a hardware problem...) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Sep 7 12:22:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f87JM7b17657 for linux-xfs-outgoing; Fri, 7 Sep 2001 12:22:07 -0700 Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f87JM2d17638 for ; Fri, 7 Sep 2001 12:22:03 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id 2BA11139DC; Fri, 7 Sep 2001 15:22:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id 28A77139DA; Fri, 7 Sep 2001 15:22:09 -0400 (EDT) Date: Fri, 7 Sep 2001 15:22:09 -0400 (EDT) From: Mike Burger To: Eric Sandeen Cc: Subject: Re: fsck equivalent? In-Reply-To: <3B991C24.9493F1C0@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well, yesterday it was the disappearance of everything in the /var directory. I shutdown and rebooted the system, and received a message during boot that /dev/hdb1 couldn't be mounted due to missing file system or bad superblock. df showed mounts of /dev/hda1 (/boot), /devhda2 (/) and /dev/hdc1 (/home). I tried, just for kicks, to fsck /dev/hdb1, but it came back with a message about a bad superblock (as it should have.) I then tried to mkfs.xfs /dev/hdb1, and it came back with a message that there was already an XFS filesystem on the device. The system, upon POST, does recognize the drive, just fine, physically...but this is the third time I've lost the /var filesystem. Right now, after trying to do a remote shutdown -r now, the system is hung, at some point, which I won't be able to view until I get back onsite. On Fri, 7 Sep 2001, Eric Sandeen wrote: > Mike Burger wrote: > > > > I've got a drive that I think is flakey...but right now, it holds my > > /var file system. I've done some considerable customization (considering > > that the installation of the OS only occurred yesterday) and I'd hate to > > have to reinstall the whole damned OS, again. > > > > So, since the drive can't be mounted (error involves bad superblock), I'm > > in need of the name of a program I can run, manually, to check and repair > > the filesystem, if possible, so that I can then move the contents off to > > a replacement drive. > > You can try xfs_repair - the filesystem should be unmounted, and you can > give it the "-n" option to see what it _would_ do, without actually > doing anything. > > What sort of errors did you run into? (Just making sure it's a hardware > problem...) > > -Eric > > > From owner-linux-xfs@oss.sgi.com Fri Sep 7 12:32:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f87JW3U17890 for linux-xfs-outgoing; Fri, 7 Sep 2001 12:32:03 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f87JVxd17871 for ; Fri, 7 Sep 2001 12:31:59 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f87JVr524473 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Fri, 7 Sep 2001 12:31:53 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA142342 for ; Fri, 7 Sep 2001 21:31:57 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2916792; Fri, 7 Sep 2001 14:30:33 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA60629; Fri, 7 Sep 2001 14:30:33 -0500 (CDT) Message-ID: <3B992055.AE786AC5@sgi.com> Date: Fri, 07 Sep 2001 14:30:29 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Mike Burger CC: linux-xfs@oss.sgi.com Subject: Re: fsck equivalent? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mike Burger wrote: > > Well, yesterday it was the disappearance of everything in the /var > directory. I shutdown and rebooted the system, and received a message > during boot that /dev/hdb1 couldn't be mounted due to missing file system > or bad superblock. Hm, that's a generic mount error message that will happen for a variety of reasons... Sort of "windows-esque" if you ask me. :) Any other messages in the syslogs when you try to mount it? > df showed mounts of /dev/hda1 (/boot), /devhda2 (/) and /dev/hdc1 (/home). > > I tried, just for kicks, to fsck /dev/hdb1, but it came back with a > message about a bad superblock (as it should have.) Actually, fsck should have run fsck.xfs, which is pretty simple: int main(int argc, char **argv) { return 0; } :) > I then tried to > mkfs.xfs /dev/hdb1, and it came back with a message that there was > already an XFS filesystem on the device. Well, that's good news... I suppose it's pretty possible that it is a bad disk, just wondered what you had run into. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Sep 7 12:40:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f87JesX18080 for linux-xfs-outgoing; Fri, 7 Sep 2001 12:40:54 -0700 Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f87Jeod18061 for ; Fri, 7 Sep 2001 12:40:50 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id 7FC61139DC; Fri, 7 Sep 2001 15:40:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id 7CC4B139DA; Fri, 7 Sep 2001 15:40:56 -0400 (EDT) Date: Fri, 7 Sep 2001 15:40:56 -0400 (EDT) From: Mike Burger To: Eric Sandeen Cc: Subject: Re: fsck equivalent? In-Reply-To: <3B992055.AE786AC5@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 7 Sep 2001, Eric Sandeen wrote: > Mike Burger wrote: > > > > Well, yesterday it was the disappearance of everything in the /var > > directory. I shutdown and rebooted the system, and received a message > > during boot that /dev/hdb1 couldn't be mounted due to missing file system > > or bad superblock. > > Hm, that's a generic mount error message that will happen for a variety > of reasons... > Sort of "windows-esque" if you ask me. :) Well, Windows used to be on the hard drive, but it's a non-booting slave, drive, now...dedicated entirely to XFS and Linux. > Any other messages in the syslogs when you try to mount it? No way for me to know...since it's the drive that houses /var, I can't get to the syslogs. I can reboot and note the errors that come up during boot. Most of them involve not being able to find the appropriate dirctories under /var for lock files, PID files, etc. > > df showed mounts of /dev/hda1 (/boot), /devhda2 (/) and /dev/hdc1 (/home). > > > > I tried, just for kicks, to fsck /dev/hdb1, but it came back with a > > message about a bad superblock (as it should have.) > > Actually, fsck should have run fsck.xfs, which is pretty simple: I kinda thought so, too... > > I then tried to > > mkfs.xfs /dev/hdb1, and it came back with a message that there was > > already an XFS filesystem on the device. > > Well, that's good news... > I suppose it's pretty possible that it is a bad disk, just wondered what > you had run into. I'll be rebooting into single user mode and trying xfs.repair on the drive when I get home...I'll let you know what I come up with, if anything. From owner-linux-xfs@oss.sgi.com Fri Sep 7 14:06:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f87L61J19246 for linux-xfs-outgoing; Fri, 7 Sep 2001 14:06:01 -0700 Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f87L5ud19227 for ; Fri, 7 Sep 2001 14:05:56 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id 25CD7139E1; Fri, 7 Sep 2001 17:06:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id 1CA84139DF; Fri, 7 Sep 2001 17:06:03 -0400 (EDT) Date: Fri, 7 Sep 2001 17:06:02 -0400 (EDT) From: Mike Burger To: Eric Sandeen Cc: Subject: Re: fsck equivalent? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well, the good news is that I didn't lose the /var filesystem, this time...but I did lose the database that I had just created (no data in it, though, so it works out ok. ). xfs_repair did help, though. On Fri, 7 Sep 2001, Mike Burger wrote: > On Fri, 7 Sep 2001, Eric Sandeen wrote: > > > Mike Burger wrote: > > > > > > Well, yesterday it was the disappearance of everything in the /var > > > directory. I shutdown and rebooted the system, and received a message > > > during boot that /dev/hdb1 couldn't be mounted due to missing file system > > > or bad superblock. > > > > Hm, that's a generic mount error message that will happen for a variety > > of reasons... > > Sort of "windows-esque" if you ask me. :) > > Well, Windows used to be on the hard drive, but it's a non-booting slave, > drive, now...dedicated entirely to XFS and Linux. > > > Any other messages in the syslogs when you try to mount it? > > No way for me to know...since it's the drive that houses /var, I can't get > to the syslogs. > > I can reboot and note the errors that come up during boot. Most of them > involve not being able to find the appropriate dirctories under /var for > lock files, PID files, etc. > > > > df showed mounts of /dev/hda1 (/boot), /devhda2 (/) and /dev/hdc1 (/home). > > > > > > I tried, just for kicks, to fsck /dev/hdb1, but it came back with a > > > message about a bad superblock (as it should have.) > > > > Actually, fsck should have run fsck.xfs, which is pretty simple: > > I kinda thought so, too... > > > > I then tried to > > > mkfs.xfs /dev/hdb1, and it came back with a message that there was > > > already an XFS filesystem on the device. > > > > Well, that's good news... > > > > > I suppose it's pretty possible that it is a bad disk, just wondered what > > you had run into. > > I'll be rebooting into single user mode and trying xfs.repair on the drive > when I get home...I'll let you know what I come up with, if anything. > > From owner-linux-xfs@oss.sgi.com Fri Sep 7 15:23:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f87MN5P20820 for linux-xfs-outgoing; Fri, 7 Sep 2001 15:23:05 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f87MN2d20800 for ; Fri, 7 Sep 2001 15:23:03 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA09345; Sat, 8 Sep 2001 00:22:56 +0200 (CEST) Message-Id: <4.3.2.7.2.20010908002120.035e8b20@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 08 Sep 2001 00:23:06 +0200 To: Mike Burger , Eric Sandeen From: Seth Mos Subject: Re: fsck equivalent? Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 17:06 7-9-2001 -0400, Mike Burger wrote: >Well, the good news is that I didn't lose the /var filesystem, this >time...but I did lose the database that I had just created (no data in it, >though, so it works out ok. ). If you see this often can you then specify sopme details like what compiler you used ig you compiled your own or what hardware you are on. >xfs_repair did help, though. As it should :-) Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Sep 7 16:47:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f87NlCq22610 for linux-xfs-outgoing; Fri, 7 Sep 2001 16:47:12 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f87Nl1d22590 for ; Fri, 7 Sep 2001 16:47:01 -0700 Received: from cvo-exchange.cvo.roguewave.com (cvo-ext.roguewave.com [12.22.36.198]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA03605 for ; Fri, 7 Sep 2001 16:46:58 -0700 (PDT) mail_from (petersp@roguewave.com) Received: by cvo-exchange.roguewave.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Sep 2001 16:45:24 -0700 Message-ID: From: Poul Petersen To: linux-xfs@oss.sgi.com, linux-scsi@vger.kernel.org Subject: Problems with 2.4.5 + XFS 1.0.1 + qlogicfc driver Date: Fri, 7 Sep 2001 16:45:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've been noticing a problem which I have worked down to a reliable test case. We have a SAN with three servers (2 Dell 6450 dual CPU and a Dell Optiplex Gx running RedHat 7.1 with the 2.4.5 kernel (SMP enabled on the duals) and XFS 1.0.1) a Qualstar tape library, and a Zzyzx RocketStor 2000 disk array. These machines are all connected together with a SANbox. The Dell's have Qlogic 2100 cards and are running the stock qlogicfc kernel driver as a module. Other than XFS, we have modified the scsi_scan.c driver (patch below). Everything else is unchanged. I orignally observed the problem with the tape library and created the following test case: 1) unload st, sg, qlogicfc from host 2) unplug Qualstar library from SAN 3) load qlogic on host 4) mount a disk on host from the Zzyzx array 5) start a large dd write to the disk 6) load st,sg module on host 7) plug Qualstar library into SAN 8) unload sg (or st) This sequence of actions will cause the host running the dd's to report I/O errors and eventually force the disk offline. On occassion, I had been able to duplicate this by simply connecting the library to the san while a disk write is occuring. We worked around this problem by installing a second HBA into the Optiplex and plugging the tape library directly into this host, effectively isolating the library from the rest of the SAN (this one machine is the backup server, so it's no big deal.) However, early today one of the Dell servers crashed and when we rebooted it the *other* Dell, which serves the disk space on the SAN via NFS, reported the attached errors in its log. When I tried to unexport the file-system and unmount the disk, the VFS dies with the all too pleasant "Have a nice day" error. We then rebooted the machine and all of the disks recovered OK. Should I run xfs_repair manually, or is the recovery XFS runs at mount sufficient? Any ideas on how we can avoid this in the future? Thanks! -poul Sep 7 14:01:05 albatross kernel: qlogicfc0 : RSCN Received Sep 7 14:01:05 albatross kernel: qlogicfc0 : Fabric found. Sep 7 14:01:05 albatross kernel: qlogicfc0 : Error performing port login 4008 Sep 7 14:01:05 albatross kernel: qlogicfc0 : Port Database Sep 7 14:01:05 albatross kernel: wwn: 210000e08b02bcf9 scsi_id: 0 loop_id: 0 Sep 7 14:01:05 albatross kernel: wwn: 210000e08b02e5f9 scsi_id: 1 loop_id: Not Available Sep 7 14:01:05 albatross kernel: wwn: 201200208d010d71 scsi_id: 2 loop_id: Not Available Sep 7 14:01:05 albatross kernel: wwn: 201000208d010d71 scsi_id: 3 loop_id: 81 Sep 7 14:01:05 albatross kernel: wwn: 201300208d010d71 scsi_id: 4 loop_id: 82 Sep 7 14:01:05 albatross kernel: wwn: 201100208d010d71 scsi_id: 5 loop_id: 83 Sep 7 14:01:05 albatross kernel: wwn: 210000e08b02dcf9 scsi_id: 6 loop_id: 84 Sep 7 14:01:37 albatross kernel: qlogicfc0 : scsi abort failure: 4006 Sep 7 14:01:37 albatross kernel: qlogicfc0 : abort failed Sep 7 14:01:37 albatross kernel: qlogicfc0 : firmware status is 4000 3 Sep 7 14:01:37 albatross kernel: qlogicfc0 : scsi abort failure: 4006 Sep 7 14:01:37 albatross kernel: qlogicfc0 : abort failed Sep 7 14:01:37 albatross kernel: qlogicfc0 : firmware status is 4000 3 ..etc.. Sep 7 14:01:38 albatross kernel: scsi: device set offline - command error recover failed: host 2 channel 0 id 2 lun 0 Sep 7 14:01:38 albatross kernel: SCSI disk error : host 2 channel 0 id 2 lun 0 return code = 6040000 Sep 7 14:01:38 albatross kernel: I/O error: dev 08:21, sector 125941000 Sep 7 14:01:38 albatross kernel: XFS: device 0x821- XFS write error in file system meta-data block 0x781b508 in sd(8,33) Sep 7 14:01:38 albatross kernel: I/O error: dev 08:21, sector 100740168 Sep 7 14:01:38 albatross kernel: I/O error: dev 08:21, sector 100740400 Sep 7 14:01:38 albatross kernel: I/O error: dev 08:21, sector 100741088 ...etc... many many lines here... Sep 7 14:01:40 albatross kernel: I/O error: dev 08:21, sector 16864360 Sep 7 14:01:40 albatross kernel: I/O error: dev 08:21, sector 25165825 Sep 7 14:01:40 albatross kernel: I/O error: dev 08:21, sector 25165848 Sep 7 14:01:40 albatross kernel: I/O error: dev 08:21, sector 25168072 Sep 7 14:01:40 albatross kernel: I/O error: dev 08:21, sector 25173472 Sep 7 14:01:44 albatross kernel: SCSI disk error : host 2 channel 0 id 2 lun 0 return code = 6040000 Sep 7 14:01:44 albatross kernel: I/O error: dev 08:21, sector 125829376 Sep 7 14:01:44 albatross kernel: xfs_force_shutdown(sd(8,33),0x2) called from line 942 of file xfs_log.c. Return address = 0xc01d580d Sep 7 14:01:44 albatross kernel: I/O Error Detected. Shutting down filesystem: sd(8,33) Sep 7 14:01:45 albatross kernel: Please umount the filesystem, and rectify the problem(s) Sep 7 14:01:45 albatross kernel: I/O error: dev 08:21, sector 42011112 Sep 7 14:01:45 albatross kernel: xfs_force_shutdown(sd(8,33),0x2) called from line 714 of file xfs_log.c. Return address = 0xc01d5527 Sep 7 14:01:45 albatross kernel: xfs_force_shutdown(sd(8,33),0x2) called from line 714 of file xfs_log.c. Return address = 0xc01d5527 Sep 7 14:01:45 albatross kernel: SCSI disk error : host 2 channel 0 id 2 lun 0 return code = 6040000 Sep 7 14:01:45 albatross kernel: I/O error: dev 08:21, sector 41969056 Sep 7 14:01:45 albatross kernel: SCSI disk error : host 2 channel 0 id 2 lun 0 return code = 6040000 Sep 7 14:01:45 albatross kernel: I/O error: dev 08:21, sector 92286648 Sep 7 14:01:45 albatross kernel: I/O error: dev 08:21, sector 92286655 Sep 7 14:01:45 albatross kernel: xfs_force_shutdown(sd(8,33),0x2) called from line 942 of file xfs_log.c. Return address = 0xc01d580d Sep 7 14:01:45 albatross kernel: I/O error: dev 08:21, sector 67525328 Sep 7 14:01:45 albatross kernel: I/O error in filesystem ("sd(8,33)") meta-data dev 0x821 block 0x4065ad0: Sep 7 14:01:45 albatross kernel: xfs_trans_read_buf --- scsi_scan.c.orig Mon Jul 23 09:24:53 2001 +++ scsi_scan.c Thu Jul 26 16:29:14 2001 @@ -153,6 +153,8 @@ {"DELL", "PSEUDO DEVICE .", "*", BLIST_SPARSELUN}, // Dell PV 530F {"DELL", "PV530F", "*", BLIST_SPARSELUN}, // Dell PV 530F {"EMC", "SYMMETRIX", "*", BLIST_SPARSELUN}, + {"CMD", "CRA-7280", "*", BLIST_SPARSELUN}, // CMD RAID Controller + {"Zzyzx", "RocketStor 2000S", "*", BLIST_SPARSELUN}, // Zzyzx RocketStor Raid {"SONY", "TSL", "*", BLIST_FORCELUN}, // DDS3 & DDS4 autoloaders {"DELL", "PERCRAID", "*", BLIST_FORCELUN}, {"HP", "NetRAID-4M", "*", BLIST_FORCELUN}, @@ -565,20 +567,26 @@ } /* - * Check the peripheral qualifier field - this tells us whether LUNS - * are supported here or not. + * Check for SPARSELUN before checking the peripheral qualifier, + * so sparse lun devices are completely scanned. */ - if ((scsi_result[0] >> 5) == 3) { - scsi_release_request(SRpnt); - return 0; /* assume no peripheral if any sort of error */ - } /* * Get any flags for this device. */ bflags = get_device_flags (scsi_result); - + if (bflags & BLIST_SPARSELUN) { + *sparse_lun = 1; + } + /* + * Check the peripheral qualifier field - this tells us whether LUNS + * are supported here or not. + */ + if ((scsi_result[0] >> 5) == 3) { + scsi_release_request(SRpnt); + return 0; /* assume no peripheral if any sort of error */ + } /* The Toshiba ROM was "gender-changed" here as an inline hack. This is now much more generic. This is a mess: What we really want is to leave the scsi_result From owner-linux-xfs@oss.sgi.com Fri Sep 7 23:04:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8864WA28407 for linux-xfs-outgoing; Fri, 7 Sep 2001 23:04:32 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8864Ud28388 for ; Fri, 7 Sep 2001 23:04:30 -0700 Received: from idcomm.com (IDENT:olWK+amd5CygftXhVjK8BazaslJ45HzK@x2-pip57.idcomm.com [209.60.72.68]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f886EaQ10485 for ; Sat, 8 Sep 2001 00:14:36 -0600 Message-ID: <3B99B55E.CF8F4F16@idcomm.com> Date: Sat, 08 Sep 2001 00:06:22 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: ".", "..", and cd Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is probably not an XFS question per se, but might be, I'm not sure. I use XFS on the root system, and am working on some directory and file scanning code. One of the banes of this is to scan for files or directories beginning with ".", without always viewing the current directory and its parent directory, "..". While doing some testing of special cases, I discovered that if I look for files in the root directory "/" (on XFS), through the "glob" function (which presumably is used in code of some shells for its pattern matching), looking for files of pattern ".*", then doing so in "/" results in both "/./" (I have the flag set to append "/" to the end of directory values) and "/../". This latter entry is a curiosity, seeing as the root partition does not have a parent. If I cd to "/", and then do "cd ..", there is no error either, I just end up where I started. Is this the standard, expected behavior (possibly POSIX or HFS designated)? Or would different filesystems behave differently, where some complain about "cd .." when already in the root? At this point it is really nothing more than a curiosity, but it sticks out during testing. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Fri Sep 7 23:13:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f886Dqh28690 for linux-xfs-outgoing; Fri, 7 Sep 2001 23:13:52 -0700 Received: from mail.fmonkey.net (24-28-209-226.ff.cox.rr.com [24.28.209.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f886Dmd28671 for ; Fri, 7 Sep 2001 23:13:48 -0700 Received: (qmail 8467 invoked from network); 8 Sep 2001 06:12:31 -0000 Received: from softdnserror (HELO galadriel) (192.168.11.1) by 192.168.11.25 with SMTP; 8 Sep 2001 06:12:31 -0000 From: "Adam H. Pendleton" To: , Subject: RE: ".", "..", and cd Date: Sat, 8 Sep 2001 02:13:08 -0400 Message-ID: <000101c1382d$60694500$fb0aa8c0@galadriel> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3B99B55E.CF8F4F16@idcomm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I don't have the "correct" answer to this question, but I am using a box with reiserfs as its root partition (shh, it's my dirty little secret -- don't tell anyone), and a "cd .." on the root partition gives me no error. Adam H. Pendleton -----Original Message----- From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com] On Behalf Of D. Stimits Sent: Saturday, September 08, 2001 02:06 To: XFS: linux-xfs@oss.sgi.com Subject: ".", "..", and cd This is probably not an XFS question per se, but might be, I'm not sure. I use XFS on the root system, and am working on some directory and file scanning code. One of the banes of this is to scan for files or directories beginning with ".", without always viewing the current directory and its parent directory, "..". While doing some testing of special cases, I discovered that if I look for files in the root directory "/" (on XFS), through the "glob" function (which presumably is used in code of some shells for its pattern matching), looking for files of pattern ".*", then doing so in "/" results in both "/./" (I have the flag set to append "/" to the end of directory values) and "/../". This latter entry is a curiosity, seeing as the root partition does not have a parent. If I cd to "/", and then do "cd ..", there is no error either, I just end up where I started. Is this the standard, expected behavior (possibly POSIX or HFS designated)? Or would different filesystems behave differently, where some complain about "cd .." when already in the root? At this point it is really nothing more than a curiosity, but it sticks out during testing. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Fri Sep 7 23:18:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f886I8u28875 for linux-xfs-outgoing; Fri, 7 Sep 2001 23:18:08 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f886I5d28856 for ; Fri, 7 Sep 2001 23:18:05 -0700 Received: (qmail 29707 invoked from network); 8 Sep 2001 06:18:01 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 8 Sep 2001 06:18:01 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 4D514300090; Sat, 8 Sep 2001 16:17:14 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 2C86EAA; Sat, 8 Sep 2001 16:17:14 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: stimits@idcomm.com Cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: ".", "..", and cd In-reply-to: Your message of "Sat, 08 Sep 2001 00:06:22 CST." <3B99B55E.CF8F4F16@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Sep 2001 16:17:08 +1000 Message-ID: <4765.999929828@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 08 Sep 2001 00:06:22 -0600, "D. Stimits" wrote: >If I cd to "/", and then do "cd ..", there is no error either, >Is this the standard, expected behavior (possibly POSIX or HFS >designated)? Every hierarchical filesystem I have ever worked on has this behaviour, / is its own parent. Even non-Unix hierarchical systems do this. From owner-linux-xfs@oss.sgi.com Sat Sep 8 00:26:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f887QuA29802 for linux-xfs-outgoing; Sat, 8 Sep 2001 00:26:56 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f887Qpd29782 for ; Sat, 8 Sep 2001 00:26:51 -0700 Received: from idcomm.com (IDENT:i6mVzjMmujgFTaggmfFy1kGerRW0an/M@x2-pip57.idcomm.com [209.60.72.68]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f887awQ15465 for ; Sat, 8 Sep 2001 01:36:58 -0600 Message-ID: <3B99C8AF.57BBDA78@idcomm.com> Date: Sat, 08 Sep 2001 01:28:47 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: ".", "..", and cd References: <4765.999929828@ocs3.intra.ocs.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > > On Sat, 08 Sep 2001 00:06:22 -0600, > "D. Stimits" wrote: > >If I cd to "/", and then do "cd ..", there is no error either, > >Is this the standard, expected behavior (possibly POSIX or HFS > >designated)? > > Every hierarchical filesystem I have ever worked on has this behaviour, > / is its own parent. Even non-Unix hierarchical systems do this. Ok, this makes sense, it allows a state-machine description with no undefined state when it is defined that "." and ".." are properties of every node. (an arrow circling back to point at the node it starts from) D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Sat Sep 8 00:37:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f887bgD30054 for linux-xfs-outgoing; Sat, 8 Sep 2001 00:37:42 -0700 Received: from dms.digistar.com (root@digistar.com [216.88.176.30]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f887bcd30034 for ; Sat, 8 Sep 2001 00:37:38 -0700 Received: from localhost (alanb@localhost) by dms.digistar.com (8.12.0.Beta19/8.11.5) with ESMTP id f887baej001822 for ; Sat, 8 Sep 2001 02:37:37 -0500 Date: Sat, 8 Sep 2001 02:37:36 -0500 (CDT) From: Alan Brown To: Subject: Patch comments. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk 1: Judicious use of the --exclude-from directive will keep your patch virgin vs third party stuff you may have incorporated to your source tree. Right now your filesystem patch is fundamentally incompatible with things like Alan Cox's jumbo patches because of this. Also your inclusion of non-related code may interfere with application of other single patches people may be applying. 2: Why submit these to Linus? The guy is snowed under and has more pressing priorities right now in his life than including patches to stable code (other than bugfixes). You're really better off cleaning up your patches and feeding them to Alan Cox. There's a large pool of ac-testers out there, your code will get tested and debugged faster this way and you'll end up in the mainstream kernel tree that much more quickly. (incidentally, Linus' priorities are why 2.4.* releases are such a pig right now. The ac trees are more stable in my experience.) AB From owner-linux-xfs@oss.sgi.com Sat Sep 8 05:42:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f88CgeB01672 for linux-xfs-outgoing; Sat, 8 Sep 2001 05:42:40 -0700 Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f88Cgbd01653 for ; Sat, 8 Sep 2001 05:42:37 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id 260F8139E0; Sat, 8 Sep 2001 08:42:34 -0400 (EDT) To: linux-xfs@oss.sgi.com Subject: kernel-BOOT? Message-Id: <20010908124234.260F8139E0@linux.compucomis.net> Date: Sat, 8 Sep 2001 08:42:34 -0400 (EDT) From: mburger@compucomis.net (Mike Burger) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well, after seeming to again lose the /var filesystem, I went ahead and replaced the drive where it was stored...all seems to be well, now, with it. So, I thought I'd go ahead and upgrade to the 2.4.5-SGI_XFS kernel. I've downloaded each of the processor specific rpms (deciding which I'll use), as well as the kernel headers and kernel-source packages. I'm wondering, though, about the kernel-BOOT package. I noticed that the SGI installer did not install that package on my system, so I was wondering what the kernel-BOOT package is/does, and whether or not I need it for anything. Thanks. --Mike From owner-linux-xfs@oss.sgi.com Sat Sep 8 06:43:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f88DhLW02652 for linux-xfs-outgoing; Sat, 8 Sep 2001 06:43:21 -0700 Received: from mta01ps.bigpond.com (juicer46.bigpond.com [144.135.25.133]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f88DhDd02625 for ; Sat, 8 Sep 2001 06:43:13 -0700 Received: from HERCULES ([144.135.25.81]) by mta01ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GJCJQ400.12P for ; Sat, 8 Sep 2001 23:49:16 +1000 Received: from CPE-61-9-140-28.vic.bigpond.net.au ([61.9.140.28]) by psmam05.mailsvc.email.bigpond.com(MailRouter V2.9i 8410/4021714); 08 Sep 2001 23:49:16 Content-Type: text/plain; charset="iso-8859-1" From: Adrian Head Reply-To: adrian.head@bytecomm.com.au To: linux-xfs@oss.sgi.com Subject: Problems with many processes copying large directories across an XFS volume. Date: Sat, 8 Sep 2001 23:43:07 +1000 X-Mailer: KMail [version 1.2] Organization: Bytecomm P/L MIME-Version: 1.0 Message-Id: <01090823430700.01184@HERCULES> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am in the process of building a couple of file servers for various purposes and over the last week have been running quite a few tests in an attempt to determine if I trust the hardware/software combination enough for it to be put into production. One of the tests I was doing was trying to simulate many users copying large directories across an XFS volume. To do this I was generating many background jobs copying a 4G directory to another directory on the XFS volume. eg. #>cp -r 001 002& #>cp -r 001 003& #>cp -r 001 004& ..... ..... #>cp -r 001 019& #>cp -r 001 020& Everything would start fine but less than a minute into the test various hundreds of errors are displayed like: cp: cannot stat file `/mnt/raid5/filename`: Input/output error Once this has happened the XFS volume disappears. By this I mean that it is still mounted but all files and directories are no longer visible using ls. Any other file activity results in an Input/Output error. Once I unmount & mount the volume again the data is again visible up to the point where the copy failed. In the /var/log/messages log around the same time as the copy test I get entries like: Sep 9 05:13:46 ATLAS kernel: 02:86: rw=0, want=156092516, limit=360 Sep 9 05:13:46 ATLAS kernel: attempt to access beyond end of device The problem is reproduceable on XFS volumes on a 2 disk (IDE) raid0 (SW raid) partition and on a 5 disk (IDE) raid5 (SW raid) partition. However, there is no problem with the copy test using ext2 volumes on the above partitions. The copy test also passes when run on a non-raid drive. I am using Kernel 2.4.9 and the relevant latest XFS patch from the patches directory on the XFS ftp site. patch-2.4.9-xfs-2001-08-19 The thing that really puzzles me is that the above directory copy test runs fine when I only have 10 background copy jobs running at a time. As soon as I have 20 background copy jobs running the problem occurs. The system passes both bonnie++ and mongo.pl tests/benchmarks. So from the results I have at the moment it would seem that XFS is stomping over the raid code or the raid code is stomping over XFS. Should I cross post this to the raid list as well? P.S. I have just noticed on the mailing list archive a note about fixing a problem that caused mongo.pl to hang. Although my systems don't hang in mongo do people think I'm seeing the same problem just a different symptom? Another issue that I think is not related is that when using the 2.4.9-xfs kernel, when the kernel identifies the drives during bootup I get IRQ probe failed errors. hda: IC35L040AVER07-0, ATA DISK drive hda: IRQ probe failed (0xfffffff8) hdb: IC35L040AVER07-0, ATA DISK drive hdb: IRQ probe failed (0xfffffff8) ........the rest as normal The errors occur when the kernel is run on an ASUS A7V133 motherboard but not on a ASUS A7V133C. The errors don't happen with a native 2.4.9 kernel either. Since the errors occur for the 2 drives on the 1st channel of the 1st IDE controller (which is not related to the raid arrays mentioned above) and the system still boots - I have not been worried about it. Should I be worried? At this stage I'm unsure what other info people would like. If anyone wants logs, config files, more information or more testing please tell me. Thanks for your time. Adrian Head Bytecomm P/L From owner-linux-xfs@oss.sgi.com Sat Sep 8 09:30:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f88GUcu05000 for linux-xfs-outgoing; Sat, 8 Sep 2001 09:30:38 -0700 Received: from picklock.adams.family ([145.254.147.195]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f88GUWd04981 for ; Sat, 8 Sep 2001 09:30:33 -0700 Received: from loewe-komp.de (localhost [127.0.0.1]) by picklock.adams.family (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id f88GXjL16623 for ; Sat, 8 Sep 2001 18:33:45 +0200 Message-ID: <3B9A4869.1FF5D169@loewe-komp.de> Date: Sat, 08 Sep 2001 18:33:45 +0200 From: Peter =?iso-8859-1?Q?W=E4chtler?= Organization: B16 X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.4.9-ac5 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Patch comments. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alan Brown wrote: > > 1: Judicious use of the --exclude-from directive will keep your patch > virgin vs third party stuff you may have incorporated to your source > tree. > > Right now your filesystem patch is fundamentally incompatible with > things like Alan Cox's jumbo patches because of this. > > Also your inclusion of non-related code may interfere with application > of other single patches people may be applying. > > 2: Why submit these to Linus? The guy is snowed under and has more > pressing priorities right now in his life than including patches to > stable code (other than bugfixes). > > You're really better off cleaning up your patches and feeding them to > Alan Cox. There's a large pool of ac-testers out there, your code will > get tested and debugged faster this way and you'll end up in the > mainstream kernel tree that much more quickly. I want to second this. New functionality like drivers or even filesystems should first be included in the -ac series of the Linux kernel. The other option would be to include it in 2.5 - but this will give you: no xfs in "user" kernel for the next year ;) From owner-linux-xfs@oss.sgi.com Sat Sep 8 12:02:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f88J2ws06434 for linux-xfs-outgoing; Sat, 8 Sep 2001 12:02:58 -0700 Received: from c4solutions.net (IDENT:qmailr@mail.c4solutions.net [216.143.5.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f88J2ud06415 for ; Sat, 8 Sep 2001 12:02:56 -0700 Received: (qmail 865 invoked by uid 100); 8 Sep 2001 19:02:53 -0000 To: linux-xfs@oss.sgi.com Subject: Kickstart on Bootable CDROM Message-ID: <999975773.3b9a6b5d2b4e0@www.c4solutions.net> Date: Sat, 08 Sep 2001 15:02:53 -0400 (EDT) From: Barrett Gay MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 216.143.5.139 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm trying to create an automated install using kickstart off a bootable cd. I specify the install method as "cdrom" in my ks.cfg on the cd. When I boot the cd, it gives me the error: "No install method specified in Kickstart". However, if I use the same image (with the same kickstart file) on a floppy, the install goes fine. Any ideas? Should I specify the install method as Harddrive and point it to /tmp/cdrom? Thanks, Barrett From owner-linux-xfs@oss.sgi.com Sat Sep 8 17:43:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f890hRb11429 for linux-xfs-outgoing; Sat, 8 Sep 2001 17:43:27 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f890hNd11410 for ; Sat, 8 Sep 2001 17:43:23 -0700 Received: (qmail 1504 invoked from network); 9 Sep 2001 00:43:20 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 9 Sep 2001 00:43:20 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id DEA3D300095; Sun, 9 Sep 2001 10:42:34 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id D23B0AB; Sun, 9 Sep 2001 10:42:34 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: mburger@compucomis.net (Mike Burger) Cc: linux-xfs@oss.sgi.com Subject: Re: kernel-BOOT? In-reply-to: Your message of "Sat, 08 Sep 2001 08:42:34 -0400." <20010908124234.260F8139E0@linux.compucomis.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Sep 2001 10:42:29 +1000 Message-ID: <12875.999996149@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 8 Sep 2001 08:42:34 -0400 (EDT), mburger@compucomis.net (Mike Burger) wrote: >I'm wondering, though, about the kernel-BOOT package. I noticed that >the SGI installer did not install that package on my system, so I was >wondering what the kernel-BOOT package is/does, and whether or not I >need it for anything. rpm -qip /mnt/cdrom/RedHat/RPMS/kernel-BOOT-2.4.2-2.i386.rpm This package includes a trimmed down version of the Linux kernel. This kernel is used on the installation boot disks only and should not be used for an installed system, as many features in this kernel are turned off because of the size constraints. From owner-linux-xfs@oss.sgi.com Sat Sep 8 18:45:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f891j2L12333 for linux-xfs-outgoing; Sat, 8 Sep 2001 18:45:02 -0700 Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f891ixd12304 for ; Sat, 8 Sep 2001 18:44:59 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id 20B21139E4; Sat, 8 Sep 2001 21:45:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id 1D6FB139DC; Sat, 8 Sep 2001 21:45:07 -0400 (EDT) Date: Sat, 8 Sep 2001 21:45:07 -0400 (EDT) From: Mike Burger To: Keith Owens Cc: Subject: Re: kernel-BOOT? In-Reply-To: <12875.999996149@ocs3.intra.ocs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Aaahhh...thanks. That explains it. On Sun, 9 Sep 2001, Keith Owens wrote: > On Sat, 8 Sep 2001 08:42:34 -0400 (EDT), > mburger@compucomis.net (Mike Burger) wrote: > >I'm wondering, though, about the kernel-BOOT package. I noticed that > >the SGI installer did not install that package on my system, so I was > >wondering what the kernel-BOOT package is/does, and whether or not I > >need it for anything. > > rpm -qip /mnt/cdrom/RedHat/RPMS/kernel-BOOT-2.4.2-2.i386.rpm > This package includes a trimmed down version of the Linux kernel. > This kernel is used on the installation boot disks only and should > not be used for an installed system, as many features in this kernel > are turned off because of the size constraints. > > From owner-linux-xfs@oss.sgi.com Sun Sep 9 02:59:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f899xoU18361 for linux-xfs-outgoing; Sun, 9 Sep 2001 02:59:50 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f899xMd18341 for ; Sun, 9 Sep 2001 02:59:22 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id CAA08654 for ; Sun, 9 Sep 2001 02:59:29 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA27842; Sun, 9 Sep 2001 20:57:56 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id UAA42103; Sun, 9 Sep 2001 20:57:53 +1100 (AEDT) Date: Sun, 9 Sep 2001 20:57:52 +1100 From: Nathan Scott To: Jan Kara , Bret Giddings Cc: linux-xfs@oss.sgi.com, samba-technical@lists.samba.org Subject: [patch] Re: XFS, Quotas and Samba Message-ID: <20010909205752.A397355@wobbly.melbourne.sgi.com> References: <7AC902A40BEDD411A3A800D0B7847B660882F5@sernt14.essex.ac.uk> <20010906105952.B345981@wobbly.melbourne.sgi.com> <20010906123515.A380241@wobbly.melbourne.sgi.com> <20010906163441.C24754@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010906163441.C24754@atrey.karlin.mff.cuni.cz>; from jack@suse.cz on Thu, Sep 06, 2001 at 04:34:41PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi, On Thu, Sep 06, 2001 at 04:34:41PM +0200, Jan Kara wrote: > Hello, > > Actually it depends whether the samba code was compiled with > proper kernel headers. If so the Q_GETQUOTA is defined to be > right value and so everything should work fine. Ok, to be more > precise the utils probably won't compile in that case as struct dqblk > is no more and mem_dqblk should be used instead... But anyway it shouldn't > break silently. Hmm ... I can't see any case where the new VFS quota code will work (ie. Jan's patches/AC kernels/Redhat 7.1+) with the smbd code, even if the kernel headers happened to correspond to the running kernel. As I understand it, the new code returns a u64 byte count in one field (curspace) where before there was a u32 block count (curblocks). Is that correct? If so, smbd is in a bit of strife here cos it peeks at that field in particular... I took a stab at implementing the fix for this problem and for XFS quota - the XFS code should be correct, the VFS quota code (v1/v2 stuff) should be too, but I'm less certain on that - see attached patch. The approach is basically to attempt the old Linux quotactl for non-XFS filesystems - if that fails, try the new version. And for XFS filesystems, always use the XFS quotactl command, which is always the right thing to do. Bret - could you let me know if this helps you? cheers. > > > Just a quick followup - this is what I mentioned in my earlier > > mail to you. I think your new VFS quota code (as in Alan Cox's > > series of 2.4 kernels, for the Samba folk) will have exactly the > > same problem as XFS. This "grep" would seem to confirm it - but > > you'll know better than I here: > > > > 11:31 nathans@troppo ~/cvs/quota-tools 73> grep GETQUOTA dqblk*h > > dqblk_rpc.h:#define Q_RPC_GETQUOTA 0x0300 /* get limits and usage */ > > dqblk_v1.h:#define Q_V1_GETQUOTA 0x300 > > dqblk_v2.h:#define Q_V2_GETQUOTA 0x0D00 /* Get limits and usage */ > > dqblk_xfs.h:#define Q_XFS_GETQUOTA Q_XGETQUOTA > > 11:31 nathans@troppo ~/cvs/quota-tools 74> > > > > The samba code does a good old Q_GETQUOTA (ie. your V1 above). > > > > cheers. > > > > > > On Thu, Sep 06, 2001 at 10:59:52AM +1100, Nathan Scott wrote: > > > hi, > > > > > > On Wed, Sep 05, 2001 at 02:57:39PM +0100, Giddings, Bret wrote: > > > > I am investigating whether I can replace my expensive Compaq Alphas file > > > > servers with cheaper (and invariably faster given my budget) Intel based > > > > ones. I have so far been pleased with the ease with which xfs has installed > > > > and run on my hardware of choice. To make my life easier, I have picked up > > > > the pre-built RedHat kernels with xfs support. Everything appears to be fine > > > > except that when connecting to a share from Samba, the amount of free space > > > > reported is the amount of free disk space left on the device rather than the > > > > amount of free space in the users quota (this is on a disk mounted with > > > > usrquota and a quota set for the users). The usual tools (edquota, setquota > > > > work as expected). > > > > > > > > I have downloaded the source rpm for samba and it appears that RedHat build > > > > their smbd to support quotas. I have also checked whether > > > > /usr/include/sys/quota.h is modified by installing your updated quota rpm > > > > (quota-3.01pre8) and it isn't. So, is there another reason why quotas don't > > > > appear to work with xfs/samba? > > > > > > The samba code needs to be updated to support XFS quota under > > > Linux. There was someone on the list a little while ago who > > > was looking to add in the samba support for XFS quota, but I > > > don't know how far they got. > > > > > > I know very little about samba unfortunately, but it should be > > > quite simple to add this stuff for XFS - the disk_quotas() > > > routine in samba-2.2.1a/source/smbd/quotas.c is all that needs > > > to be changed, by the look of things. > > > > > > For XFS filesystems on Linux this needs to: > > > - have logic to handle getmntent's of type "xfs" separately; > > > - issue a quotactl(QCMD(Q_XGETQUOTA,USRQUOTA), ..., &xdq) where > > > xdq is of type "struct fs_disk_quota_t" from > > > - set *bsize to 512 for XFS > > > - refer to the code later in that same file for dealing with XFS > > > on IRIX - basically, do exactly the same thing and it should > > > just work. > > > - to do it properly, the configure scripts will need to check > > > for linux/xqm.h (or might be simpler to keep a local copy? - > > > I dunno what sort of policy the samba folk have on this sort of > > > thing, but this header isn't going to change and probably isn't > > > going to appear in the libc headers for quite awhile...) > > > > > > cheers. > > > > > > -- > > > Nathan > > > > -- > > Nathan > -- > Jan Kara > SuSE Labs -- Nathan --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="smbd+quota.patch" diff -Naur samba-2.2.1a/source/smbd/quotas.c samba-2.2.1a+ns/source/smbd/quotas.c --- samba-2.2.1a/source/smbd/quotas.c Thu Jul 5 21:02:03 2001 +++ samba-2.2.1a+ns/source/smbd/quotas.c Sun Sep 9 09:29:58 2001 @@ -44,13 +44,10 @@ #ifdef LINUX #include -#include +#include #include - #include -#include - -_syscall4(int, quotactl, int, cmd, const char *, special, int, id, caddr_t, addr); +#include "quotas.h" /**************************************************************************** try to get the disk space from disk quotas (LINUX version) @@ -59,18 +56,20 @@ BOOL disk_quotas(char *path, SMB_BIG_UINT *bsize, SMB_BIG_UINT *dfree, SMB_BIG_UINT *dsize) { int r; - struct dqblk D; + v1_kern_dqblk_t D1; + v2_kern_dqblk_t D2; + fs_disk_quota_t DX; SMB_STRUCT_STAT S; FILE *fp; struct mntent *mnt; SMB_DEV_T devno; int found; uid_t euser_id; + static int version = 1; /* VFS quota version */ euser_id = geteuid(); - + /* find the block device file */ - if ( sys_stat(path, &S) == -1 ) { return(False) ; } @@ -91,47 +90,109 @@ endmntent(fp) ; if (!found) { - return(False); - } + return(False); + } save_re_uid(); set_effective_uid(0); - r=quotactl(QCMD(Q_GETQUOTA,USRQUOTA), mnt->mnt_fsname, euser_id, (caddr_t)&D); + if (strcmp(mnt->mnt_type, "xfs") == 0) + r = quotactl(QCMD(Q_XGETQUOTA,USRQUOTA), mnt->mnt_fsname, euser_id, (caddr_t)&DX); + else { + if (version == 1) { + r = quotactl(QCMD(Q_V1_GETQUOTA,USRQUOTA), mnt->mnt_fsname, euser_id, (caddr_t)&D1); + if (r == EINVAL) + version = 2; + } + if (version == 2) + r = quotactl(QCMD(Q_V2_GETQUOTA,USRQUOTA), mnt->mnt_fsname, euser_id, (caddr_t)&D2); + } restore_re_uid(); - /* Use softlimit to determine disk space, except when it has been exceeded */ - *bsize = 1024; if (r) - { - if (errno == EDQUOT) - { - *dfree =0; - *dsize =D.dqb_curblocks; - return (True); - } - else return(False); + return(False); + + if (version == 1) + { + *bsize = 1024; + /* Use softlimit to determine disk space, except when its been exceeded */ + if ( + (D1.dqb_bsoftlimit && D1.dqb_curblocks>=D1.dqb_bsoftlimit) || + (D1.dqb_bhardlimit && D1.dqb_curblocks>=D1.dqb_bhardlimit) || + (D1.dqb_isoftlimit && D1.dqb_curinodes>=D1.dqb_isoftlimit) || + (D1.dqb_ihardlimit && D1.dqb_curinodes>=D1.dqb_ihardlimit) + ) + { + *dfree = 0; + *dsize = D1.dqb_curblocks; + } + else if (D1.dqb_bsoftlimit==0 && D1.dqb_bhardlimit==0) + { + return(False); + } + else + { + if (D1.dqb_bsoftlimit == 0) + D1.dqb_bsoftlimit = D1.dqb_bhardlimit; + *dfree = D1.dqb_bsoftlimit - D1.dqb_curblocks; + *dsize = D1.dqb_bsoftlimit; + } + } + else if (version == 2) + { + *bsize = 1024; + D2.dqb_curspace >>= 10; /* bytes to Kbytes */ + /* Use softlimit to determine disk space, except when its been exceeded */ + if ( + (D2.dqb_bsoftlimit && D2.dqb_curspace >=D2.dqb_bsoftlimit) || + (D2.dqb_bhardlimit && D2.dqb_curspace >=D2.dqb_bhardlimit) || + (D2.dqb_isoftlimit && D2.dqb_curinodes>=D2.dqb_isoftlimit) || + (D2.dqb_ihardlimit && D2.dqb_curinodes>=D2.dqb_ihardlimit) + ) + { + *dfree = 0; + *dsize = D2.dqb_curspace; + } + else if (D2.dqb_bsoftlimit==0 && D2.dqb_bhardlimit==0) + { + return(False); + } + else + { + if (D2.dqb_bsoftlimit == 0) + D2.dqb_bsoftlimit = D2.dqb_bhardlimit; + *dfree = D2.dqb_bsoftlimit - D2.dqb_curspace; + *dsize = D2.dqb_bsoftlimit; + } } - /* Use softlimit to determine disk space, except when it has been exceeded */ - if ( - (D.dqb_bsoftlimit && D.dqb_curblocks>=D.dqb_bsoftlimit) || - (D.dqb_bhardlimit && D.dqb_curblocks>=D.dqb_bhardlimit) || - (D.dqb_isoftlimit && D.dqb_curinodes>=D.dqb_isoftlimit) || - (D.dqb_ihardlimit && D.dqb_curinodes>=D.dqb_ihardlimit) - ) + else if (strcmp(mnt->mnt_type, "xfs") == 0) + { + *bsize = 512; + /* Use softlimit to determine disk space, except when its been exceeded */ + if ( + (DX.d_blk_softlimit && DX.d_bcount>=DX.d_blk_softlimit) || + (DX.d_blk_hardlimit && DX.d_bcount>=DX.d_blk_hardlimit) || + (DX.d_ino_softlimit && DX.d_icount>=DX.d_ino_softlimit) || + (DX.d_ino_hardlimit && DX.d_icount>=DX.d_ino_hardlimit) + ) { *dfree = 0; - *dsize = D.dqb_curblocks; + *dsize = DX.d_bcount; } - else if (D.dqb_bsoftlimit==0 && D.dqb_bhardlimit==0) + else if (DX.d_blk_softlimit==0 && DX.d_blk_hardlimit==0) { return(False); } - else { - if (D.dqb_bsoftlimit == 0) - D.dqb_bsoftlimit = D.dqb_bhardlimit; - *dfree = D.dqb_bsoftlimit - D.dqb_curblocks; - *dsize = D.dqb_bsoftlimit; + else + { + *dfree = (DX.d_blk_softlimit - DX.d_bcount); + *dsize = DX.d_blk_softlimit; + } } + else + { + return(False); + } + return (True); } diff -Naur samba-2.2.1a/source/smbd/quotas.h samba-2.2.1a+ns/source/smbd/quotas.h --- samba-2.2.1a/source/smbd/quotas.h Wed Dec 31 19:00:00 1969 +++ samba-2.2.1a+ns/source/smbd/quotas.h Sun Sep 9 09:29:58 2001 @@ -0,0 +1,58 @@ +#ifdef LINUX + +#define Q_V1_GETQUOTA 0x0300 /* VFS quota, version 1 */ +#define Q_V2_GETQUOTA 0x0D00 /* VFS quota, version 2 */ +#define Q_XGETQUOTA (('X'<<8)+0x3) /* XFS quota */ + +/* struct for Q_V1_GETQUOTA */ +typedef struct v1_kern_dqblk { + u_int32_t dqb_bhardlimit; /* absolute limit on disk blks alloc */ + u_int32_t dqb_bsoftlimit; /* preferred limit on disk blks */ + u_int32_t dqb_curblocks; /* current block count */ + u_int32_t dqb_ihardlimit; /* maximum # allocated inodes */ + u_int32_t dqb_isoftlimit; /* preferred inode limit */ + u_int32_t dqb_curinodes; /* current # allocated inodes */ + time_t dqb_btime; /* time limit for excessive disk use */ + time_t dqb_itime; /* time limit for excessive files */ +} v1_kern_dqblk_t; + +/* struct for Q_V2_GETQUOTA */ +typedef u_int64_t qsize_t; +typedef struct v2_kern_dqblk { + unsigned int dqb_ihardlimit; + unsigned int dqb_isoftlimit; + unsigned int dqb_curinodes; + unsigned int dqb_bhardlimit; + unsigned int dqb_bsoftlimit; + qsize_t dqb_curspace; + time_t dqb_btime; + time_t dqb_itime; +} v2_kern_dqblk_t; + +/* struct for Q_XGETQUOTA */ +typedef struct fs_disk_quota { + __s8 d_version; /* version of this structure */ + __s8 d_flags; /* XFS_{USER,PROJ,GROUP}_QUOTA */ + __u16 d_fieldmask; /* field specifier */ + __u32 d_id; /* user, project, or group ID */ + __u64 d_blk_hardlimit; /* absolute limit on disk blks */ + __u64 d_blk_softlimit; /* preferred limit on disk blks */ + __u64 d_ino_hardlimit; /* maximum # allocated inodes */ + __u64 d_ino_softlimit; /* preferred inode limit */ + __u64 d_bcount; /* # disk blocks owned by the user */ + __u64 d_icount; /* # inodes owned by the user */ + __s32 d_itimer; /* zero if within inode limits */ + __s32 d_btimer; /* similar to above; for disk blocks */ + __u16 d_iwarns; /* # warnings issued wrt num inodes */ + __u16 d_bwarns; /* # warnings issued wrt disk blocks */ + __s32 d_padding2; /* padding2 - for future use */ + __u64 d_rtb_hardlimit; /* absolute limit on realtime blks */ + __u64 d_rtb_softlimit; /* preferred limit on RT disk blks */ + __u64 d_rtbcount; /* # realtime blocks owned */ + __s32 d_rtbtimer; /* similar to above; for RT disk blks */ + __u16 d_rtbwarns; /* # warnings issued wrt RT disk blks */ + __s16 d_padding3; /* padding3 - for future use */ + char d_padding4[8]; /* yet more padding */ +} fs_disk_quota_t; + +#endif /* LINUX */ --82I3+IH0IqGh5yIs-- From owner-linux-xfs@oss.sgi.com Sun Sep 9 04:22:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f89BMPG21847 for linux-xfs-outgoing; Sun, 9 Sep 2001 04:22:25 -0700 Received: from exocore.com ([202.4.185.25]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f89BMJd21385 for ; Sun, 9 Sep 2001 04:22:20 -0700 Received: (from shanu@localhost) by exocore.com (8.11.6/8.11.6) id f89BMcW03319 for linux-xfs@oss.sgi.com; Sun, 9 Sep 2001 16:52:38 +0530 Date: Sun, 9 Sep 2001 16:52:38 +0530 From: Shanker Balan To: Linux-XFS Subject: Re: Umask bug in the Installer - Solved? Message-ID: <20010909165238.E1750@exocore.com> Reply-To: Shanker Balan Mail-Followup-To: Linux-XFS References: <3B8BA1ED.8B5CCBC3@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B8BA1ED.8B5CCBC3@sgi.com>; from sandeen@sgi.com on Tue, Aug 28, 2001 at 08:51:41AM -0500 Organisation: Exocore Consulting (P) Ltd Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello: Eric Sandeen wrote, > We did not re-spin the original ISO, but if you use one of the two > above methods when installing, everything will be fine... Ok. I will use the updated boot floppy meth0d. Thank you for your time. -- Darth Vader: Your powers are weak, old man. Ben (Obi-Wan) Kenobi: You can't win, Darth. If you strike me down, I shall become more powerful than you could possibly imagine. From owner-linux-xfs@oss.sgi.com Sun Sep 9 09:03:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f89G3QL28292 for linux-xfs-outgoing; Sun, 9 Sep 2001 09:03:26 -0700 Received: from mail21.jump.net (mail21.jump.net [206.196.91.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f89G3Nd28273 for ; Sun, 9 Sep 2001 09:03:24 -0700 Received: from there (jump-redback-BRYA0012.jump.net [216.30.81.5] (may be forged)) by mail21.jump.net (8.11.6/) with SMTP id f89G3NM22280 for ; Sun, 9 Sep 2001 11:03:23 -0500 (CDT) Message-Id: <200109091603.f89G3NM22280@mail21.jump.net> Content-Type: text/plain; charset="iso-8859-1" From: Bryan Payne Reply-To: damasta@teknospy.com To: linux-xfs@oss.sgi.com Subject: Mounting onboard raid Date: Sun, 9 Sep 2001 11:05:32 -0500 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have onboard raid. I only use it so I can have 8 drives so there is actually no raid running. Here is the situation: I have 3 harddrives. Hda has a swap, an ext2 boot and a xfs root. Hdb is xfs and Hdg is xfs. If I attempt to mount hdg1, I get the wrong fs type error. However, I moved hdg to to hdb and it mounts fine. Is this because of the highpoint controller? The funny thing is I can mount hdg as vfat. I haven't tried it as ext2 though. Any suggestions? -- Linux, Multimedia and More... http://www.teknospy.com From owner-linux-xfs@oss.sgi.com Sun Sep 9 10:15:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f89HFsw29060 for linux-xfs-outgoing; Sun, 9 Sep 2001 10:15:54 -0700 Received: from sciurus.rentec.com (sciurus.rentec.com [192.5.35.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f89HFkd29041 for ; Sun, 9 Sep 2001 10:15:46 -0700 Received: from rentec.com (pooh [172.16.99.2]) by sciurus.rentec.com (8.11.3/8.11.3) with ESMTP id f89HFab22853; Sun, 9 Sep 2001 13:15:37 -0400 (EDT) Message-ID: <3B9BA43B.5020904@rentec.com> Date: Sun, 09 Sep 2001 13:17:47 -0400 From: Dirk Wetter User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010817 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: Karsten =?ISO-8859-1?Q?K=FCnne?= Subject: 10minutes for rm -rf on 400MB Content-Type: multipart/alternative; boundary="------------060407080307050309050409" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --------------060407080307050309050409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, we've been running XFS on the data disks of our HPC Linux cluster since a while. we are quite happy with xfs, thx guys for your work! the setup is: - dual >=1GHZ box, 4GB mem - lvm 0.9beta7, phys. volume size ~140 GB, logical vol for xfs: 100GB - no additional mount options or options for mkfs.xfs were given - kernel 2.4.8pre4-xfs, highly patched SuSE 7.0 (not that it should matter) a user complained that /rm -rf of 400MB / takes ~10 minutes (!) until the command returns, whereas on the systems with reiserfs we have e.g. it takes seconds. i don't know so much about the quality of the data, my guess is that some files are small (~100k), others a big (a few hundred MB). i read in the FAQ that XFS isn't particular good in rm-rf'ing files, which isn't really *the *issue for us, because in 99.9%of the time data is being read from the volume and not removed via rm -rf. is there an mount/filecreation option to tweak without loosing performance while reading? cheers, ~dirkw --------------060407080307050309050409 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Hi,

we've been running XFS on the data disks of our HPC Linux cluster since
a while. we are quite happy with xfs, thx guys for your work!
the setup is:

- dual >=1GHZ box, 4GB mem
- lvm 0.9beta7, phys. volume size ~140 GB, logical vol for xfs: 100GB
- no additional mount options or options for mkfs.xfs were given
- kernel 2.4.8pre4-xfs, highly patched SuSE 7.0 (not that it should matter)

a user complained that rm -rf of 400MB  takes ~10 minutes (!) until the
command returns, whereas on the systems with reiserfs we have e.g. it
takes seconds.

i don't know so much about the quality of the data, my guess is that some files
are small (~100k), others a big (a few hundred MB). i read in the FAQ that
XFS isn't particular good in rm-rf'ing  files, which isn't really the issue for
us, because in 99.9%of the time data is being read from the volume and not
removed via rm -rf.

is there an mount/filecreation option to tweak without loosing performance while
reading?



cheers,
                ~dirkw





--------------060407080307050309050409-- From owner-linux-xfs@oss.sgi.com Sun Sep 9 15:06:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f89M6h331969 for linux-xfs-outgoing; Sun, 9 Sep 2001 15:06:43 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f89M6fd31950 for ; Sun, 9 Sep 2001 15:06:41 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f89M6YB14098 for linux-xfs@oss.sgi.com; Sun, 9 Sep 2001 18:06:34 -0400 Date: Sun, 9 Sep 2001 18:06:34 -0400 From: Alan Eldridge To: SGI XFS Dev List Subject: ftp.thebarn.com Message-ID: <20010909180634.A14095@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is Russell's CVSup daemon dead? Or is something else wrong? I can traceroute it but I can't do a CVSup connect. :( -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Sun Sep 9 16:58:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f89NwrO00371 for linux-xfs-outgoing; Sun, 9 Sep 2001 16:58:53 -0700 Received: from ente.berdmann.de (frnk-d5141a34.dsl.mediaWays.net [213.20.26.52]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f89Nwmd00352 for ; Sun, 9 Sep 2001 16:58:48 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 15gETJ-00030Q-00; Mon, 10 Sep 2001 01:58:41 +0200 Message-ID: <3B9C0231.67E2BF01@berdmann.de> Date: Mon, 10 Sep 2001 01:58:41 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.10-pre4-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Dirk Wetter CC: Linux XFS Mailing List Subject: Re: 10minutes for rm -rf on 400MB References: <3B9BF400.1050900@rentec.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >we've been running XFS on the data disks of our HPC Linux cluster since
>a while. we are quite happy with xfs, thx guys for your work!
>the setup is:
>
>- dual >=1GHZ box, 4GB mem
>- lvm 0.9beta7, phys. volume size ~140 GB, logical vol for xfs: 100GB
>- no additional mount options or options for mkfs.xfs were given
>- kernel 2.4.8pre4-xfs, highly patched SuSE 7.0 (not that it should matter)
>
>a user complained that rm -rf of 400MB  takes ~10 minutes (!) until >the
>command returns, whereas on the systems with reiserfs we have e.g. it
>takes seconds.
Some very important data is missing: - what's the I/O performance of the disk subsystem? - what was the system doing during the observed 10 min? CPU power doesn't count as much as disk I/O performance because unlink(2) on XFS is a synchronous operation. >i don't know so much about the quality of the data, my guess is that some >files
>are small (~100k), others a big (a few hundred MB). i read in the FAQ that
>XFS isn't particular good in rm-rf'ing  files, which isn't really the >issue for
>us, because in 99.9%of the time data is being read from the volume and not >
>removed via rm -rf.
So, three files à 100 MB and 1,024 files à 100 KB are 400 MB in sum and even a busy system shouldn't take 10 min for deleting 1,027 files. I guess your estimate of the file sizes is slightly wrong. From owner-linux-xfs@oss.sgi.com Sun Sep 9 17:40:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A0etH00847 for linux-xfs-outgoing; Sun, 9 Sep 2001 17:40:55 -0700 Received: from sciurus.rentec.com (sciurus.rentec.com [192.5.35.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A0eld00828 for ; Sun, 9 Sep 2001 17:40:48 -0700 Received: from rentec.com (pooh [172.16.99.2]) by sciurus.rentec.com (8.11.3/8.11.3) with ESMTP id f8A0eeb22988; Sun, 9 Sep 2001 20:40:40 -0400 (EDT) Message-ID: <3B9C0C8B.2070201@rentec.com> Date: Sun, 09 Sep 2001 20:42:51 -0400 From: Dirk Wetter User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010817 X-Accept-Language: en-us MIME-Version: 1.0 To: "Bernhard R. Erdmann" CC: Linux XFS Mailing List Subject: Re: 10minutes for rm -rf on 400MB References: <3B9BF400.1050900@rentec.com> <3B9C0231.67E2BF01@berdmann.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8A0emd00829 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, Bernhard R. Erdmann wrote: >>we've been running XFS on the data disks of our HPC Linux cluster since >>a while. we are quite happy with xfs, thx guys for your work! >>the setup is: >> >>- dual >=1GHZ box, 4GB mem >>- lvm 0.9beta7, phys. volume size ~140 GB, logical vol for xfs: 100GB >>- no additional mount options or options for mkfs.xfs were given >>- kernel 2.4.8pre4-xfs, highly patched SuSE 7.0 (not that it should matter) >> >>a user complained that "rm -rf of 400MB" takes ~10 minutes (!) until >>the >>command returns, whereas on the systems with reiserfs we have e.g. it >>takes seconds. >> > >Some very important data is missing: >- what's the I/O performance of the disk subsystem? > why is that relevant? with reiserfs it takes seconds, so the disks/controller cannot be the bottleneck. but to answer your question: we don't have hamster cage style disks hooked up, in this case the lvm containing XFS is a concatenated volume over to 10krpm 72GB IBM SCSI disks on a single channel of a plain aic controller. which disk subsystem you think would take 10 minutes for the task? > >- what was the system doing during the observed 10 min? > don't know, since i wasn't doing that. but my good guess is nothing else. also if the system would have been in really use, we don't see high i/o read numbers. > >CPU power doesn't count as much as disk I/O performance because >unlink(2) on XFS is a synchronous operation. > :-( why is that? >>i don't know so much about the quality of the data, my guess is that some >>files >>are small (~100k), others a big (a few hundred MB). i read in the FAQ that >>XFS isn't particular good in rm-rf'ing files, which isn't really the >>issue for >>us, because in 99.9% of the time data is being read from the volume and not >>removed via rm -rf. >> > >So, three files à 100 MB and 1,024 files à 100 KB are 400 MB in sum and >even a busy system shouldn't take 10 min for deleting 1,027 files. I >guess your estimate of the file sizes is slightly wrong. > as i said above, the number of 10 minutes is what i was told. i am not working with our HPC cluster, i set it up. concerning the estimate of the file size, this is also info i got. and since the dataset is a couple of 10GB, i am not really into headcounting here. consider it please as an estimate and pick a lower number if it doesn't make sense. so, again the question: are there mkfs options or mount options which i should set, without bringing the filesystem into imbalance? i'd love to have my users not to experience this dent, since they won't likely accept this and despite other technical reasons might vote against using xfs. cheers, ~dirkw ______________________________ Dirk Wetter @ Renaissance Techn. mailto: From owner-linux-xfs@oss.sgi.com Sun Sep 9 18:10:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A1AOJ01279 for linux-xfs-outgoing; Sun, 9 Sep 2001 18:10:24 -0700 Received: from gusi.leathercollection.ph (postfix@gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A1AJd01255 for ; Sun, 9 Sep 2001 18:10:19 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id CEE41C00B61 for ; Mon, 10 Sep 2001 09:10:16 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 71331C00B60 for ; Mon, 10 Sep 2001 09:10:15 +0800 (PHT) Date: Mon, 10 Sep 2001 09:10:15 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: 10minutes for rm -rf on 400MB In-Reply-To: <3B9BA43B.5020904@rentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 9 Sep 2001 at 13:17, Dirk Wetter wrote: > a user complained that /rm -rf of 400MB / takes ~10 minutes (!) until > the command returns, whereas on the systems with reiserfs we have e.g. > it takes seconds. This is expected. XFS does deletes synchronously. ReiserFS doesn't. ReiserFS is really good at deleting, as a matter of fact, for which reason I highly recommend it over any other Linux filesystem for such delete-intensive operations as Squid caches. You may be interested to study the mongo.pl results comparing ReiserFS and XFS for various file sizes in . > i don't know so much about the quality of the data, my guess is that > some files are small (~100k), others a big (a few hundred MB). Note that ~100k is not small relative to the mongo.pl benchmarks that will show you that XFS starts "beating" ReserFS in most performances except deletes at around 10k. So IMHO you're still better off with XFS. > i read in the FAQ that XFS isn't particular good in rm-rf'ing files, > which isn't really *the *issue for us, because in 99.9%of the time > data is being read from the volume and not removed via rm -rf. It's not good for deleting massive numbers of files. Deleting one large file is instantaneous, though. But like you said, 99.9% (only?) of the time, you don't delete all your data, right? Unless you're talking of a cache. > is there an mount/filecreation option to tweak without loosing > performance while reading? None that I know of. One developer (was it Steve Lord? I can't remember clearly now) joked that you could mount the filesystem synchronously. That way you don't feel the speed difference. Hahaha. :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Sun Sep 9 18:41:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A1fD101816 for linux-xfs-outgoing; Sun, 9 Sep 2001 18:41:13 -0700 Received: from femail25.sdc1.sfba.home.com (femail25.sdc1.sfba.home.com [24.254.60.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A1fBd01797 for ; Sun, 9 Sep 2001 18:41:11 -0700 Received: from there ([24.10.81.118]) by femail25.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010910014106.YHFS569.femail25.sdc1.sfba.home.com@there> for ; Sun, 9 Sep 2001 18:41:06 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Mike Reply-To: machack@sscsonline.org Organization: SSCS To: Linux XFS Mailing List Subject: ac kernels Date: Sun, 9 Sep 2001 21:21:50 -0400 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Message-Id: <20010910014106.YHFS569.femail25.sdc1.sfba.home.com@there> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8A1fBd01798 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just a quick question. Is there anybody working to create a patch for the ac kernels? -- http://machack.sscsonline.org/ZapQuake/ Don't just play quake feel it! Free Dmitry Sklyarov! http://www.freesklyarov.org/ From owner-linux-xfs@oss.sgi.com Sun Sep 9 19:00:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A20fO02220 for linux-xfs-outgoing; Sun, 9 Sep 2001 19:00:41 -0700 Received: from mailin10.bigpond.com (juicer35.bigpond.com [139.134.6.87]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A20Wd02193 for ; Sun, 9 Sep 2001 19:00:32 -0700 Received: from HERCULES ([144.135.24.69]) by mailin10.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GJFCIZ00.6LE for ; Mon, 10 Sep 2001 12:06:35 +1000 Received: from CPE-61-9-140-28.vic.bigpond.net.au ([61.9.140.28]) by bwmam01.mailsvc.email.bigpond.com(MailRouter V2.9i 8311/11141664); 10 Sep 2001 12:06:35 Content-Type: text/plain; charset="iso-8859-1" From: Adrian Head Reply-To: adrian.head@bytecomm.com.au To: linux-xfs@oss.sgi.com Subject: Re: Problems with many processes copying large directories across an XFS volume. Date: Mon, 10 Sep 2001 12:00:30 +1000 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01091012003000.01147@HERCULES> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Over the last few days I have had the opportunity to try a few more tests to try and find more information to describe the problem I am seeing when I run multiple copy jobs in the background across an XFS volume. I downloaded the 2.4.9-xfs-2001-08-26 kernel patch from the XFS ftp server and gave it a run with the multiple cp test. After running through the same procedure as in my previous post - a few minutes into the test I still got the Input/Output error messages printed on the console, but this time I also had the following messages printed in /var/log/messages: Sep 10 10:14:57 ATLAS kernel: I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x9802bdc Sep 10 10:14:57 ATLAS kernel: (xlog_iodone") error 5 buf count 32768 Sep 10 10:14:57 ATLAS kernel: xfs_force_shutdown(md(9,0),0x2) called from line 940 of file xfs_log.c. Return address - 0xd8cb66f8 Sep 10 10:14:57 ATLAS kernel: Log I/O Error Detected. Shutting down filesystem: md(9,0) Sep 10 10:14:57 ATLAS kernel: Please umount the filesystem, and rectify the problem(s) Sep 10 10:14:57 ATLAS kernel: xfs_force_shutdown(md(9,0),0x2) called from line 714 of file xfs_log.c. Return address = 0xd8cb65d3 Sep 10 10:14:57 ATLAS kernel: attempt to access beyond end of device Sep 10 10:14:57 ATLAS kernel: 02:82: rw=0, want=1602235696, limit=4 I'm not sure what these really mean or what caused the I/O error but I hope this sheds some more light on the problem. (I had to transfer this by hand so if there are any uncertainties I'll go to the effort of getting the log and posting it.) The other attempt I tried was to download the 2.4.10-pre2-xfs-2001-09-02 kernel patch and run the same multiple cp test. This time things were different: This time it did not die a few minutes into the test like the previous attempts. Because it had not died I added more background processes - 40 total instead of the 20 in the previous tests. About halfway through the test for some unknown reason one cp process segfaulted because of a null kernel pointer. Why this happened to only one cp process I'm not sure - it certainly did not affect the other processes and the test continued. The test ran fine for almost 3 hours until I noticed that all HDD activity had stopped. Thinking that the test had completed I checked the jobs in the shell and it was reported that all jobs but the one that had segfaulted were still running. I checked `top` but it showed that all cp processes were running. Thinking it might have been a hardware issue I `ls *` a couple of drives including the raid5 (SW) where I was running the test. Although it was slow everything worked as normal until I did a `du -sh` on the volume that I had run the test on - with this the console froze. I switched to another console and did a `df -h` which gave me a result. The multiple cp test had stopped with only 20G left to fill on the 154G raid5 volume (about 83% complete). I was able to ping the machine from another box on the network but I was unable to log in remotely through telnet. I left the machine for another few hours but the status did not change. In the running console I shutdown the machine. The machine started to go down but hung not long after. Nothing was written to the logs. Note: The consoles I am talking about are the virtual kind Alt+F1, Alt+F2 etc. I'm not running anything graphical just plain text consoles. Some details from 'top' (just in case it helps) up 2:45 4 users load average 40.15 40.41 40.70 66 processes 27 sleeping 39 running CPU states 0% user 36.6% sys 0% nice 63.3% idle. Mem 384520k av 381956k used 2564k free 0k shrd 216k buff 353916k cached Swap 524624 av 14464k used 510160k free The 2nd test has thrown me for a complete spin. Am I seeing the same problem as the original test or is this something else? Considering that I was pushing the machine way past what I would expect to see in the production environment do I need to worry? The IRQ probe failure I talked about in the original post still exists on both of the kernels built for these test attempts. Do I need to worry about these IRQ probe failures? At this stage I'm unsure what other info people would like.  If anyone wants logs, config files, more information or more testing please tell me. Thanks for your time. Adrian Head Bytecomm P/L From owner-linux-xfs@oss.sgi.com Sun Sep 9 20:18:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A3Idc03567 for linux-xfs-outgoing; Sun, 9 Sep 2001 20:18:39 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A3I4d03547 for ; Sun, 9 Sep 2001 20:18:04 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA23762 for ; Sun, 9 Sep 2001 20:18:06 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA37461; Mon, 10 Sep 2001 14:16:41 +1100 (EDT) Date: Mon, 10 Sep 2001 14:16:41 +1100 From: Timothy Shimmin To: Takayuki Sasaki Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump/xfsrestore failed sometimes when running QA suite 022 Message-ID: <20010910141641.L96131@boing.melbourne.sgi.com> References: <200109070837.RAA22356@tagajo.bsd.tnes.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200109070837.RAA22356@tagajo.bsd.tnes.nec.co.jp>; from sasaki@bsd.tnes.nec.co.jp on Fri, Sep 07, 2001 at 05:37:15PM +0900 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Takayuki, Do you have top of tree cmds and kernel ? cmd/xfstests/022 has failed reliably for us in recent times, but over the last few days (Nathan looks after our QA he'll know exactly when), it has been passing reliably. I have been meaning to look into 022 and 024 but only looked at 024 recently. I do not know exactly what has changed to cause 022 to pass now. xfsdump uses an xfs feature called bulkstat'ing to speed up the stat'ing of all the inodes of the file system. However, it apparently snapshots the info from the disk blocks instead of going through the in-core data structures. This means that if this data is not flushed to disk completely when xfsdump is running then it won't have the latest stat information. So for the QA testing, after populating an FS I would call _stable_fs to do sync and sleep. However, I didn't do this in every case such as the case where I append to files to test out incremental dumps in 024. So I added the call to _stable_fs in common.dump for this. I also changed from sync/sleep to umount/mount to be sure that the changes are flushed to disk before proceeding. So this may have also affected 022. However, by putting back the old behaviour I was still unable to get 022 to fail. --Tim On Fri, Sep 07, 2001 at 05:37:15PM +0900, Takayuki Sasaki wrote: > Hi, > > I have run QA suite ( cmd/xfstests/022 ) on my box, but > sometimes it failed because the size or owner of a few files are > mismatched before xfsdump / after xfsrestore. The error message > is attached at the end of this mail. > > If I edit script 022 to erase a tape with writing an eof instead > of erasing actually ( i.e. call _erase_soft instead of > _erase_hard which are defined in cmd/xfstest/common.dump ), this > issue never occured until now. > > Machine: Pentium III (Coppermine) 733MHz + SiS 630 chip set + 128MB RAM > Tape: HP C1533A DDS2 SCSI > Kernel: linux-2.4.10-pre1 with 20010829 CVS Tree > xfsdump: 20010829 CVS Tree > gcc: gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) > > This have been tested on kernel 2.4.8 and 2.4.9, but same issue > occured... Why these files are destroyed? Are there any ideas? > > Thanks in advance. > > Taka > > root [108] > ./022 > QA output created by 022 > Put scsi tape driver into variable block size mode > Creating directory system to dump using src/fsstress. > > ----------------------------------------------- > fsstress : -f link=10 -f creat=10 -f mkdir=10 -f truncate=5 -f symlink=10 > ----------------------------------------------- > Erasing tape > Dumping to tape... > xfsdump -s DUMP_SUBDIR -f TAPE_DEV -M stress_tape_media -L stress_022 SCRATCH_MNT > xfsdump: version 3.0 - Running single-threaded > xfsdump: level 0 dump of HOSTNAME:SCRATCH_MNT > xfsdump: dump date: DATE > xfsdump: session id: ID > xfsdump: session label: "stress_022" > xfsdump: ino map phase 1: parsing subtree selections > xfsdump: ino map phase 2: constructing initial dump list > xfsdump: ino map phase 3: pruning unneeded subtrees > xfsdump: ino map phase 4: estimating dump size > xfsdump: ino map phase 5: skipping (only one dump stream) > xfsdump: ino map construction complete > xfsdump: estimated dump size: NUM bytes > xfsdump: /var/xfsdump/inventory created > xfsdump: preparing drive > xfsdump: creating dump session media file 0 (media 0, file 0) > xfsdump: dumping ino map > xfsdump: dumping directories > xfsdump: dumping non-directory files > xfsdump: ending media file > xfsdump: media file size NUM bytes > xfsdump: dumping session inventory > xfsdump: beginning inventory media file > xfsdump: media file 1 (media 0, file 1) > xfsdump: ending inventory media file > xfsdump: inventory media file size NUM bytes > xfsdump: writing stream terminator > xfsdump: beginning media stream terminator > xfsdump: media file 2 (media 0, file 2) > xfsdump: ending media stream terminator > xfsdump: media stream terminator size 1048576 bytes > xfsdump: dump size (non-dir files) : NUM bytes > xfsdump: dump complete: SECS seconds elapsed > Rewinding tape > Restoring from tape... > xfsrestore -f TAPE_DEV -L stress_022 RESTORE_DIR > xfsrestore: version 3.0 - Running single-threaded > xfsrestore: using online session inventory > xfsrestore: searching media for directory dump > xfsrestore: preparing drive > xfsrestore: examining media file 0 > xfsrestore: reading directories > xfsrestore: directory post-processing > xfsrestore: restoring non-directory files > xfsrestore: restore complete: SECS seconds elapsed > Comparing listing of dump directory with restore directory > *** TMP.dump_dir Wed Aug 29 17:24:12 2001 > --- TMP.restore_dir Wed Aug 29 17:24:12 2001 > *************** > *** 13,24 **** > drwxrwxrwx 2 root root 16 Aug 29 16:16 d39 > drwxrwxrwx 5 root root 76 Aug 29 16:16 da > drwxrwxrwx 4 root root 55 Aug 29 16:16 db > ! -rw-rw-rw- 6 root root 551986 Aug 29 16:16 f21 > -rw-rw-rw- 1 root root 712704 Aug 29 16:16 f47 > -rw-rw-rw- 1 root root 0 Aug 29 16:16 f4f > ! -rw-rw-rw- 6 root root 551986 Aug 29 16:16 f6 > -rw-rw-rw- 3 root root 0 Aug 29 16:16 f61 > ! -rw-rw-rw- 6 root root 551986 Aug 29 16:16 f7 > lrwxrwxrwx 2 root root 939 Aug 29 DATE l29 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxx > lrwxrwxrwx 2 root root 939 Aug 29 DATE l29 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxx > lrwxrwxrwx 2 root root 939 Aug 29 DATE l36 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxx > --- 13,24 ---- > drwxrwxrwx 2 root root 16 Aug 29 16:16 d39 > drwxrwxrwx 5 root root 76 Aug 29 16:16 da > drwxrwxrwx 4 root root 55 Aug 29 16:16 db > ! -rw-rw-rw- 6 root root 730637 Aug 29 16:16 f21 > -rw-rw-rw- 1 root root 712704 Aug 29 16:16 f47 > -rw-rw-rw- 1 root root 0 Aug 29 16:16 f4f > ! -rw-rw-rw- 6 root root 730637 Aug 29 16:16 f6 > -rw-rw-rw- 3 root root 0 Aug 29 16:16 f61 > ! -rw-rw-rw- 6 root root 730637 Aug 29 16:16 f7 > lrwxrwxrwx 2 root root 939 Aug 29 DATE l29 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxx > lrwxrwxrwx 2 root root 939 Aug 29 DATE l29 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxx > lrwxrwxrwx 2 root root 939 Aug 29 DATE l36 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxx > *************** > *** 31,37 **** > /mnt/xfstest1/dump.1655/p0/d5/d2e: > total TOTAL > drwxrwxrwx 2 root root 26 Aug 29 16:16 d53 > ! -rw-rw-rw- 1 root root 420819 Aug 29 16:16 f2f > > /mnt/xfstest1/dump.1655/p0/d5/d2e/d53: > total TOTAL > --- 31,37 ---- > /mnt/xfstest1/dump.1655/p0/d5/d2e: > total TOTAL > drwxrwxrwx 2 root root 26 Aug 29 16:16 d53 > ! -rw-rw-rw- 1 root root 0 Aug 29 16:16 f2f > > /mnt/xfstest1/dump.1655/p0/d5/d2e/d53: > total TOTAL > *************** > *** 40,46 **** > > /mnt/xfstest1/dump.1655/p0/d5/d39: > total TOTAL > ! -rw-rw-rw- 6 root root 551986 Aug 29 16:16 f3e > > /mnt/xfstest1/dump.1655/p0/d5/da: > total TOTAL > --- 40,46 ---- > > /mnt/xfstest1/dump.1655/p0/d5/d39: > total TOTAL > ! -rw-rw-rw- 6 root root 730637 Aug 29 16:16 f3e > > /mnt/xfstest1/dump.1655/p0/d5/da: > total TOTAL > *************** > *** 55,61 **** > > /mnt/xfstest1/dump.1655/p0/d5/da/d10: > total TOTAL > ! -rw-rw-rw- 2 root root 584907 Aug 29 16:16 f62 > lrwxrwxrwx 6 root root 1018 Aug 29 DATE l25 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx > lrwxrwxrwx 6 root root 1018 Aug 29 DATE l25 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx > lrwxrwxrwx 1 root root 1011 Aug 29 DATE l5a -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxxx > --- 55,61 ---- > > /mnt/xfstest1/dump.1655/p0/d5/da/d10: > total TOTAL > ! -rw-rw-rw- 2 root root 635646 Aug 29 16:16 f62 > lrwxrwxrwx 6 root root 1018 Aug 29 DATE l25 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx > lrwxrwxrwx 6 root root 1018 Aug 29 DATE l25 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx > lrwxrwxrwx 1 root root 1011 Aug 29 DATE l5a -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxxx > *************** > *** 64,71 **** > /mnt/xfstest1/dump.1655/p0/d5/da/d14: > total TOTAL > drwxrwxrwx 4 root root 56 Aug 29 16:16 d1f > ! drwxrwxrwx 2 root root 36 Aug 29 16:16 d26 > ! -rw-rw-rw- 3 root root 1906129 Aug 29 16:16 f55 > > /mnt/xfstest1/dump.1655/p0/d5/da/d14/d1f: > total TOTAL > --- 64,71 ---- > /mnt/xfstest1/dump.1655/p0/d5/da/d14: > total TOTAL > drwxrwxrwx 4 root root 56 Aug 29 16:16 d1f > ! drwxrwxrwx 2 root root 26 Aug 29 16:16 d26 > ! -rw-rw-rw- 3 root root 956273 Aug 29 16:16 f55 > > /mnt/xfstest1/dump.1655/p0/d5/da/d14/d1f: > total TOTAL > *************** > *** 95,101 **** > > /mnt/xfstest1/dump.1655/p0/d5/da/d14/d26: > total TOTAL > - -rw-rw-rw- 1 root root 0 Aug 29 16:16 f44 > lrwxrwxrwx 2 root root 868 Aug 29 DATE l4e -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx > lrwxrwxrwx 2 root root 868 Aug 29 DATE l4e -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx > lrwxrwxrwx 1 root root 217 Aug 29 DATE l5e -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxx > --- 95,100 ---- > *************** > *** 103,109 **** > > /mnt/xfstest1/dump.1655/p0/d5/da/d22: > total TOTAL > ! -rw-rw-rw- 6 root root 551986 Aug 29 16:16 f49 > lrwxrwxrwx 1 root root 294 Aug 29 DATE l2c -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxx > lrwxrwxrwx 1 root root 294 Aug 29 DATE l2c -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxx > lrwxrwxrwx 1 root root 392 Aug 29 DATE l54 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/x > --- 102,108 ---- > > /mnt/xfstest1/dump.1655/p0/d5/da/d22: > total TOTAL > ! -rw-rw-rw- 6 root root 730637 Aug 29 16:16 f49 > lrwxrwxrwx 1 root root 294 Aug 29 DATE l2c -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxx > lrwxrwxrwx 1 root root 294 Aug 29 DATE l2c -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxx > lrwxrwxrwx 1 root root 392 Aug 29 DATE l54 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/x > *************** > *** 113,119 **** > total TOTAL > drwxrwxrwx 4 root root 46 Aug 29 16:16 d15 > drwxrwxrwx 4 root root 44 Aug 29 16:16 dc > ! -rw-rw-rw- 2 root root 1720320 Aug 29 16:16 f18 > -rw-rw-rw- 1 root root 0 Aug 29 16:16 f67 > lrwxrwxrwx 2 root root 868 Aug 29 DATE l20 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx > lrwxrwxrwx 2 root root 868 Aug 29 DATE l20 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx > --- 112,118 ---- > total TOTAL > drwxrwxrwx 4 root root 46 Aug 29 16:16 d15 > drwxrwxrwx 4 root root 44 Aug 29 16:16 dc > ! -rw-rw-rw- 2 root root 0 Aug 29 16:16 f18 > -rw-rw-rw- 1 root root 0 Aug 29 16:16 f67 > lrwxrwxrwx 2 root root 868 Aug 29 DATE l20 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx > lrwxrwxrwx 2 root root 868 Aug 29 DATE l20 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx > *************** > *** 122,128 **** > total TOTAL > drwxrwxrwx 2 root root 6 Aug 29 16:16 d30 > drwxrwxrwx 2 root root 16 Aug 29 16:16 d3a > ! -rw-rw-rw- 3 root root 1906129 Aug 29 16:16 f1e > lrwxrwxrwx 6 root root 1018 Aug 29 DATE l17 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx > lrwxrwxrwx 6 root root 1018 Aug 29 DATE l17 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx > > --- 121,127 ---- > total TOTAL > drwxrwxrwx 2 root root 6 Aug 29 16:16 d30 > drwxrwxrwx 2 root root 16 Aug 29 16:16 d3a > ! -rw-rw-rw- 3 root root 956273 Aug 29 16:16 f1e > lrwxrwxrwx 6 root root 1018 Aug 29 DATE l17 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx > lrwxrwxrwx 6 root root 1018 Aug 29 DATE l17 -> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxx > xxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxx > > *************** > *** 131,144 **** > > /mnt/xfstest1/dump.1655/p0/d5/db/d15/d3a: > total TOTAL > ! -rw-rw-rw- 3 root root 1906129 Aug 29 16:16 f6e > > /mnt/xfstest1/dump.1655/p0/d5/db/dc: > total TOTAL > drwxrwxrwx 4 root root 46 Aug 29 16:16 d11 > drwxrwxrwx 4 root root 36 Aug 29 16:16 d23 > ! -rw-rw-rw- 6 root root 551986 Aug 29 16:16 fd > ! -rw-rw-rw- 2 root root 584907 Aug 29 16:16 fe > > /mnt/xfstest1/dump.1655/p0/d5/db/dc/d11: > total TOTAL > --- 130,143 ---- > > /mnt/xfstest1/dump.1655/p0/d5/db/d15/d3a: > total TOTAL > ! -rw-rw-rw- 3 root root 956273 Aug 29 16:16 f6e > > /mnt/xfstest1/dump.1655/p0/d5/db/dc: > total TOTAL > drwxrwxrwx 4 root root 46 Aug 29 16:16 d11 > drwxrwxrwx 4 root root 36 Aug 29 16:16 d23 > ! -rw-rw-rw- 6 root root 730637 Aug 29 16:16 fd > ! -rw-rw-rw- 2 root root 635646 Aug 29 16:16 fe > > /mnt/xfstest1/dump.1655/p0/d5/db/dc/d11: > total TOTAL > *************** > *** 163,169 **** > /mnt/xfstest1/dump.1655/p0/d5/db/dc/d11/d37: > total TOTAL > -rw-rw-rw- 1 root root 0 Aug 29 16:16 f4a > ! -rw-rw-rw- 2 root root 1720320 Aug 29 16:16 f5c > > /mnt/xfstest1/dump.1655/p0/d5/db/dc/d23: > total TOTAL > --- 162,168 ---- > /mnt/xfstest1/dump.1655/p0/d5/db/dc/d11/d37: > total TOTAL > -rw-rw-rw- 1 root root 0 Aug 29 16:16 f4a > ! -rw-rw-rw- 2 root root 0 Aug 29 16:16 f5c > > /mnt/xfstest1/dump.1655/p0/d5/db/dc/d23: > total TOTAL > root [109] > > From owner-linux-xfs@oss.sgi.com Sun Sep 9 20:19:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A3JrI03654 for linux-xfs-outgoing; Sun, 9 Sep 2001 20:19:53 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A3JXd03635 for ; Sun, 9 Sep 2001 20:19:33 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA07886 for ; Sun, 9 Sep 2001 20:19:03 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id NAA21473; Mon, 10 Sep 2001 13:15:16 +1000 Date: Mon, 10 Sep 2001 13:15:16 +1000 From: Keith Owens Message-Id: <200109100315.NAA21473@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade to 2.4.10-pre5 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Upgrade to 2.4.10-pre5. This compiles but has not been tested yet. AL Viro has changed fs/super.c (again) and the dmapi patch no longer makes sense, I have ifdeffed it out so do not expect dmapi to work. Dean, it looks like do_kern_mount has to return a struct vsfmount that is marked as IS_ERR and release the superblock lock yourself. Date: Sun Sep 9 20:09:11 PDT 2001 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102419a linux/drivers/scsi/dpt/osd_util.h - 1.1 linux/include/net/bluetooth/hci_vhci.h - 1.1 linux/include/linux/prefetch.h - 1.1 linux/Documentation/arm/SA1100/DMA - 1.1 linux/Documentation/arm/SA1100/FreeBird - 1.1 linux/drivers/video/tx3912fb.h - 1.1 linux/Documentation/arm/SA1100/HUW_WEBPANEL - 1.1 linux/drivers/video/tx3912fb.c - 1.1 linux/Documentation/arm/SA1100/PCMCIA - 1.1 linux/drivers/video/sstfb.h - 1.1 linux/Documentation/arm/SA1100/Yopy - 1.1 linux/drivers/video/sstfb.c - 1.1 linux/drivers/video/radeonfb.c - 1.1 linux/Documentation/fb/README-sstfb.txt - 1.1 linux/drivers/video/radeon.h - 1.1 linux/drivers/usb/usbvideo.h - 1.1 linux/drivers/usb/usbvideo.c - 1.1 linux/drivers/telephony/ixj_pcmcia.c - 1.1 linux/drivers/telephony/ixj-ver.h - 1.1 linux/Documentation/sound/WaveArtist - 1.1 linux/drivers/sound/nec_vrc5477.c - 1.1 linux/drivers/sound/ite8172.c - 1.1 linux/drivers/scsi/dpti.h - 1.1 linux/drivers/scsi/dpt_i2o.c - 1.1 linux/drivers/scsi/dpt/sys_info.h - 1.1 linux/drivers/scsi/dpt/osd_defs.h - 1.1 linux/drivers/scsi/dpt/dptsig.h - 1.1 linux/drivers/scsi/dpt/dpti_ioctl.h - 1.1 linux/drivers/scsi/dpt/dpti_i2o.h - 1.1 linux/drivers/scsi/dpt/dpt_osdutil.h - 1.1 linux/drivers/net/starfire_firmware.pl - 1.1 linux/drivers/media/video/vino.h - 1.1 linux/drivers/ide/qd65xx.h - 1.1 linux/drivers/ide/qd65xx.c - 1.1 linux/drivers/char/serial_tx3912.h - 1.1 linux/drivers/char/serial_tx3912.c - 1.1 linux/drivers/bluetooth/hci_vhci.c - 1.1 linux/net/sunrpc/xdr.c - 1.4 linux/net/sunrpc/svc.c - 1.8 linux/net/sunrpc/sunrpc_syms.c - 1.9 linux/net/sunrpc/clnt.c - 1.13 linux/net/netrom/af_netrom.c - 1.19 linux/net/lapb/lapb_iface.c - 1.9 linux/net/irda/irda_device.c - 1.19 linux/net/ipv6/udp.c - 1.22 linux/net/ipv6/tcp_ipv6.c - 1.25 linux/net/ipv6/sit.c - 1.16 linux/net/ipv6/ip6_output.c - 1.10 linux/net/ipv6/icmp.c - 1.13 linux/net/ipv6/datagram.c - 1.8 linux/net/ipv6/addrconf.c - 1.20 linux/net/ipv4/udp.c - 1.24 linux/net/ipv4/tcp_ipv4.c - 1.33 linux/net/ipv4/ipip.c - 1.17 linux/net/ipv4/ip_output.c - 1.26 linux/net/ipv4/ip_options.c - 1.5 linux/net/ipv4/ip_fragment.c - 1.14 linux/net/ipv4/icmp.c - 1.22 linux/net/ipv4/arp.c - 1.19 linux/net/core/dev.c - 1.40 linux/kernel/ksyms.c - 1.104 linux/include/scsi/sg.h - 1.11 linux/include/linux/sunrpc/xdr.h - 1.5 linux/include/linux/module.h - 1.20 linux/include/linux/minix_fs.h - 1.10 linux/include/linux/lockd/xdr.h - 1.4 linux/include/linux/fs.h - 1.115 linux/include/asm-sparc64/system.h - 1.13 linux/include/asm-sparc64/pgtable.h - 1.22 linux/include/asm-sparc64/elf.h - 1.9 linux/fs/super.c - 1.52 linux/fs/qnx4/inode.c - 1.24 linux/fs/proc/generic.c - 1.23 linux/fs/open.c - 1.30 linux/fs/nfsd/nfsfh.c - 1.30 linux/fs/nfsd/export.c - 1.20 linux/fs/nfs/inode.c - 1.28 linux/fs/nfs/file.c - 1.23 linux/fs/minix/namei.c - 1.15 linux/fs/minix/inode.c - 1.22 linux/fs/minix/file.c - 1.11 linux/fs/minix/dir.c - 1.8 linux/fs/minix/bitmap.c - 1.11 linux/fs/lockd/clntlock.c - 1.9 linux/fs/file_table.c - 1.15 linux/fs/exec.c - 1.44 linux/fs/dquot.c - 1.35 linux/fs/adfs/inode.c - 1.16 linux/drivers/zorro/zorro.c - 1.8 linux/drivers/video/fbcon.c - 1.21 linux/drivers/usb/hub.h - 1.15 linux/drivers/usb/hub.c - 1.37 linux/drivers/sound/sonicvibes.c - 1.33 linux/drivers/sound/msnd_pinnacle.c - 1.17 linux/drivers/sound/ad1848.c - 1.12 linux/drivers/sound/Config.in - 1.27 linux/drivers/scsi/sg.c - 1.20 linux/drivers/scsi/seagate.h - 1.4 linux/drivers/scsi/seagate.c - 1.12 linux/drivers/scsi/sd.c - 1.41 linux/drivers/scsi/qlogicfc_asm.c - 1.7 linux/drivers/scsi/qlogicfc.c - 1.21 linux/drivers/scsi/gdth_proc.h - 1.5 linux/drivers/scsi/gdth_proc.c - 1.11 linux/drivers/scsi/gdth_ioctl.h - 1.4 linux/drivers/scsi/gdth.h - 1.6 linux/drivers/scsi/gdth.c - 1.14 linux/drivers/scsi/aha1542.c - 1.17 linux/drivers/net/via-rhine.c - 1.27 linux/drivers/net/ni5010.c - 1.14 linux/drivers/net/net_init.c - 1.21 linux/drivers/macintosh/nvram.c - 1.9 linux/drivers/isdn/pcbit/layer2.h - 1.5 linux/drivers/isdn/pcbit/layer2.c - 1.7 linux/drivers/isdn/isdn_audio.c - 1.8 linux/drivers/isdn/icn/icn.h - 1.8 linux/drivers/isdn/icn/icn.c - 1.14 linux/drivers/char/wdt.c - 1.12 linux/drivers/char/tty_io.c - 1.34 linux/drivers/char/tpqic02.c - 1.14 linux/drivers/char/softdog.c - 1.12 linux/drivers/char/selection.c - 1.6 linux/drivers/char/qpmouse.c - 1.11 linux/drivers/char/pc110pad.c - 1.12 linux/drivers/char/misc.c - 1.26 linux/drivers/char/dsp56k.c - 1.16 linux/drivers/char/busmouse.c - 1.17 linux/drivers/cdrom/sjcd.c - 1.11 linux/drivers/cdrom/mcdx.c - 1.9 linux/drivers/cdrom/mcd.c - 1.11 linux/drivers/cdrom/isp16.c - 1.5 linux/drivers/cdrom/gscd.c - 1.11 linux/drivers/cdrom/cm206.c - 1.12 linux/drivers/cdrom/cdu31a.c - 1.8 linux/drivers/cdrom/aztcd.c - 1.12 linux/drivers/block/rd.c - 1.31 linux/drivers/block/floppy.c - 1.26 linux/arch/sparc64/vmlinux.lds - 1.10 linux/arch/sparc64/mm/ultra.S - 1.16 linux/arch/sparc64/mm/init.c - 1.30 linux/arch/sparc64/mm/fault.c - 1.18 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.32 linux/arch/sparc64/kernel/ioctl32.c - 1.41 linux/arch/sparc64/kernel/head.S - 1.9 linux/arch/sparc64/defconfig - 1.47 linux/arch/ppc/amiga/config.c - 1.11 linux/arch/i386/mm/fault.c - 1.18 linux/arch/i386/kernel/setup.c - 1.51 linux/arch/i386/defconfig - 1.66 linux/arch/arm/mm/fault-armv.c - 1.17 linux/arch/arm/kernel/process.c - 1.19 linux/Makefile - 1.118 linux/MAINTAINERS - 1.70 linux/Documentation/watchdog.txt - 1.6 linux/Documentation/ide.txt - 1.7 linux/include/linux/ide.h - 1.31 linux/drivers/sound/cmpci.c - 1.25 linux/drivers/isdn/hisax/isar.c - 1.13 linux/arch/arm/kernel/arthur.c - 1.7 linux/Documentation/sound/CMI8338 - 1.5 linux/drivers/char/vino.h - 1.2 linux/drivers/parport/parport_pc.c - 1.37 linux/drivers/char/sx.c - 1.20 linux/drivers/sound/esssolo1.c - 1.31 linux/fs/partitions/check.c - 1.29 linux/drivers/sound/ac97.h - 1.5 linux/drivers/net/starfire.c - 1.19 linux/Documentation/arm/SA1100/Itsy - 1.2 linux/drivers/pci/pci.ids - 1.32 linux/include/linux/mmzone.h - 1.16 linux/drivers/sound/trident.h - 1.12 linux/drivers/sound/trident.c - 1.25 linux/include/linux/i2c-id.h - 1.9 linux/include/linux/telephony.h - 1.6 linux/drivers/telephony/phonedev.c - 1.7 linux/drivers/telephony/ixj.h - 1.6 linux/drivers/telephony/ixj.c - 1.17 linux/drivers/telephony/Makefile - 1.4 linux/drivers/telephony/Config.in - 1.2 linux/drivers/usb/devices.c - 1.12 linux/drivers/usb/devio.c - 1.17 linux/drivers/ieee1394/ieee1394_core.h - 1.9 linux/drivers/ieee1394/ieee1394_core.c - 1.14 linux/drivers/ieee1394/highlevel.c - 1.5 linux/drivers/scsi/3w-xxxx.h - 1.6 linux/drivers/scsi/3w-xxxx.c - 1.12 linux/drivers/zorro/names.c - 1.3 linux/drivers/usb/usb-uhci.c - 1.25 linux/drivers/sound/ac97_codec.c - 1.18 linux/drivers/sound/via82cxxx_audio.c - 1.19 linux/drivers/char/wdt977.c - 1.6 linux/drivers/char/wdt285.c - 1.8 linux/include/linux/ac97_codec.h - 1.10 linux/drivers/video/riva/fbdev.c - 1.12 linux/include/linux/usb.h - 1.18 linux/drivers/parport/ChangeLog - 1.18 linux/drivers/ide/via82cxxx.c - 1.17 linux/drivers/ide/sl82c105.c - 1.5 linux/drivers/ide/sis5513.c - 1.12 linux/drivers/ide/qd6580.c - 1.6 linux/drivers/ide/pdc202xx.c - 1.10 linux/drivers/ide/ide.c - 1.27 linux/drivers/ide/ide-proc.c - 1.7 linux/drivers/ide/ide-floppy.c - 1.8 linux/drivers/ide/Makefile - 1.10 linux/drivers/ide/Config.in - 1.13 linux/Documentation/DocBook/Makefile - 1.17 linux/include/linux/generic_serial.h - 1.3 linux/drivers/char/wdt_pci.c - 1.7 linux/Documentation/DocBook/parportbook.tmpl - 1.6 linux/drivers/usb/serial/visor.h - 1.6 linux/drivers/usb/serial/visor.c - 1.20 linux/drivers/sound/i810_audio.c - 1.14 linux/drivers/char/rio/riocmd.c - 1.6 linux/drivers/char/rio/rio_linux.c - 1.10 linux/Documentation/arm/SA1100/Assabet - 1.2 linux/Documentation/kernel-doc-nano-HOWTO.txt - 1.4 linux/Documentation/arm/SA1100/nanoEngine - 1.2 linux/drivers/sound/cs46xx.c - 1.14 linux/arch/arm/tools/mach-types - 1.8 linux/drivers/md/raid5.c - 1.18 linux/drivers/md/md.c - 1.20 linux/fs/minix/itree_common.c - 1.4 linux/fs/minix/itree_v1.c - 1.2 linux/fs/minix/itree_v2.c - 1.2 linux/Documentation/arm/SA1100/GraphicsClient - 1.2 linux/Documentation/arm/SA1100/Pangolin - 1.2 linux/Documentation/arm/SA1100/serial_UART - 1.2 linux/arch/arm/lib/io-writesl.S - 1.4 linux/fs/reiserfs/inode.c - 1.9 linux/arch/arm/lib/io-readsl-armv4.S - 1.3 linux/arch/arm/tools/Makefile - 1.3 linux/drivers/s390/char/tuball.c - 1.3 linux/drivers/s390/char/tubfs.c - 1.3 linux/drivers/s390/char/tubio.h - 1.3 linux/drivers/s390/char/tubtty.c - 1.3 linux/drivers/s390/char/tubttybld.c - 1.2 linux/Documentation/s390/3270.txt - 1.3 linux/Documentation/s390/config3270.sh - 1.2 linux/drivers/block/paride/ppc6lnx.c - 1.2 linux/drivers/usb/pwc.h - 1.4 linux/drivers/usb/pwc-if.c - 1.4 linux/drivers/bluetooth/hci_uart.c - 1.3 linux/include/net/bluetooth/bluetooth.h - 1.2 linux/include/net/bluetooth/bluez.h - 1.2 linux/include/net/bluetooth/hci.h - 1.2 linux/include/net/bluetooth/hci_core.h - 1.2 linux/include/net/bluetooth/hci_emu.h - 1.2 linux/include/net/bluetooth/hci_uart.h - 1.2 linux/include/net/bluetooth/hci_usb.h - 1.2 linux/include/net/bluetooth/l2cap.h - 1.2 linux/include/net/bluetooth/l2cap_core.h - 1.2 linux/drivers/bluetooth/hci_usb.c - 1.3 linux/drivers/bluetooth/hci_emu.c - 1.3 linux/drivers/bluetooth/Makefile - 1.2 linux/drivers/bluetooth/Config.in - 1.2 linux/net/bluetooth/af_bluetooth.c - 1.2 linux/net/bluetooth/hci_core.c - 1.2 linux/net/bluetooth/hci_sock.c - 1.2 linux/net/bluetooth/l2cap_core.c - 1.2 linux/net/bluetooth/l2cap_proc.c - 1.2 linux/net/bluetooth/lib.c - 1.2 linux/drivers/usb/se401.c - 1.4 linux/drivers/usb/se401.h - 1.2 linux/drivers/usb/serial/pl2303.c - 1.2 linux/drivers/scsi/pcmcia/nsp_cs.c - 1.5 linux/drivers/scsi/pcmcia/nsp_debug.c - 1.5 linux/drivers/parport/parport_serial.c - 1.2 linux/drivers/message/fusion/scsi3.h - 1.2 linux/drivers/message/fusion/mptscsih.c - 1.2 linux/drivers/message/fusion/mptlan.h - 1.2 linux/drivers/message/fusion/mptlan.c - 1.2 linux/drivers/message/fusion/mptctl.c - 1.3 linux/drivers/message/fusion/mptbase.h - 1.2 linux/drivers/message/fusion/mptbase.c - 1.2 linux/drivers/message/fusion/lsi/mpi_targ.h - 1.2 linux/drivers/message/fusion/lsi/mpi_lan.h - 1.2 linux/drivers/message/fusion/lsi/mpi_ioc.h - 1.2 linux/drivers/message/fusion/lsi/mpi_init.h - 1.2 linux/drivers/message/fusion/lsi/mpi_history.txt - 1.2 linux/drivers/message/fusion/lsi/mpi_fc.h - 1.2 linux/drivers/message/fusion/lsi/mpi_cnfg.h - 1.2 linux/drivers/message/fusion/lsi/mpi.h - 1.2 linux/drivers/message/fusion/Makefile - 1.2 linux/drivers/message/fusion/isense.c - 1.2 linux/drivers/message/fusion/lsi/fc_log.h - 1.2 linux/fs/partitions/ldm.c - 1.2 linux/drivers/scsi/pcmcia/nsp_message.c - 1.2 linux/drivers/ide/it8172.c - 1.2 From owner-linux-xfs@oss.sgi.com Sun Sep 9 20:29:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A3TWm03857 for linux-xfs-outgoing; Sun, 9 Sep 2001 20:29:32 -0700 Received: from gateway1.brets.elevating.com (adsl-216-63-236-137.dsl.tulsok.swbell.net [216.63.236.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A3TTd03838 for ; Sun, 9 Sep 2001 20:29:29 -0700 Received: from elevating.com (bretdell.brets.elevating.com [192.168.0.128]) by gateway1.brets.elevating.com (8.9.3/8.8.7) with ESMTP id WAA10306 for ; Sun, 9 Sep 2001 22:29:18 -0500 Message-ID: <3B9C338E.500C917B@elevating.com> Date: Sun, 09 Sep 2001 22:29:18 -0500 From: Bret Hughes X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en, ja MIME-Version: 1.0 To: linux-xfs Subject: Re: compaq smart 2 raid and XFS 1.0.1 redhat install problems References: <3B988116.E31FAF1C@elevating.com> <3B9893DB.F59296E@ch.sauter-bc.com> <20010907123728.A10983@blenke.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Ian C. Blenke" wrote: > > I'm running two VA Linux boxen with XFS/LVM, and two Compaq 1850R boxen > on SmartStart2 controllers with XFS/LVM, as well as a couple of happy XFS > laptops. I've had incredibly few problems with XFS so far.. and > lvextend/xfs_growfs really is a lifesaver. > > Good luck. > > - Ian C. Blenke Thanks to all who responded. I ended up having to follow Ians advice and wiping out everything and doing a new install. bummer. I have backups but the real pain in the neck is that this was my amanda index and tape server, so I get to dig around on the 18 tapes in my daily rotation to find the latest stuff. oh well it IS working. I have another box with the identical hardware that is really important and I am hoping that if I keep my head out of my $%# I will be able to do an upgrade. For those of you perusing the archives inthe future on a compaq proliant 3000 dual processor, 1GB memory with smart-2dh raid controller do NOT let lilo install on the MBR. I ended up making /boot as the first partition (non-XFS) and putting lilo there. works like a champ but boy was it painful. BTW I had to do the compaq erase routine and the associated build twice before it too. Not sure what I screwed up the first time. Thanks again for your help and comments. Bret From owner-linux-xfs@oss.sgi.com Sun Sep 9 21:49:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A4n5k04473 for linux-xfs-outgoing; Sun, 9 Sep 2001 21:49:05 -0700 Received: from gateway1.brets.elevating.com (adsl-216-63-236-137.dsl.tulsok.swbell.net [216.63.236.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A4n0d04454 for ; Sun, 9 Sep 2001 21:49:01 -0700 Received: from elevating.com (bretdell.brets.elevating.com [192.168.0.128]) by gateway1.brets.elevating.com (8.9.3/8.8.7) with ESMTP id XAA10551; Sun, 9 Sep 2001 23:48:50 -0500 Message-ID: <3B9C4632.2408E16@elevating.com> Date: Sun, 09 Sep 2001 23:48:50 -0500 From: Bret Hughes X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en, ja MIME-Version: 1.0 To: linux-xfs Subject: directory cache problems (I think) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have a configuration on 6 boxes, Duron 700 with 128 MB ram and 10GB ide harddrives. These machines are all XFS 1.0.1 using the kernel from the 1.0.1 RH install iso and most of the RH updates. They were all placed into service the same day and yesterday 5 days after they were turned on they all stopped responding to ssh. A couple would still respond to a ping but nothing else. Actually I caough one before it quit altogether and rebooted it last night. These machines a kiosk type display that scroll html and flash pages using (netscape as the browser). There is no user interaction infact not any input device at all. A different page is displayed every 10 seconds. Now, After rebooting them I can get to the sadc data and looking through the logs shows really bad stuff happening at 1:00PM yesterday on the one machine I have really looked at closely. interrupt 14s out the wazoo and what I think must be the cause, the dentunusd goes to 0. Looking over the logs of the last few days I can see the dentunusd creeping down from the beginning at boot of over 20K to 0. Since netscape is such a pig I kill it and restart it once an hour and restart X once a day. both these events seem to take a tremendous toll on this value and never gain it all back. I don't know if this is an XFS issue or not but I thought that I would start here. Any ideas? I can send all the log data anyone might use if it would help. Right now I am going to reboot the damn things nightly like they were windows machines for Christ's sake. BTW the same scenario and control scripts run for months on end on RH 6.2 using the 2.2.3-16 kernel. Any tips and or other places to ask are appreciated. TIA Bret From owner-linux-xfs@oss.sgi.com Sun Sep 9 21:53:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A4r1x04624 for linux-xfs-outgoing; Sun, 9 Sep 2001 21:53:01 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A4qsd04605 for ; Sun, 9 Sep 2001 21:52:55 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA08761 for ; Sun, 9 Sep 2001 21:51:22 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id OAA26810; Mon, 10 Sep 2001 14:52:30 +1000 Date: Mon, 10 Sep 2001 14:52:30 +1000 From: Keith Owens Message-Id: <200109100452.OAA26810@sherman.melbourne.sgi.com> Subject: TAKE - Sync RCS identifiers with 2.4.10-pre5 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sync RCS identifiers with 2.4.10-pre5. The use of separate respositories had resulted in a drift of RCS identifiers in ptools, compared to LInus's tree. Annoying when generating patches, so I resynced with Linus's tree. No code changes. Date: Sun Sep 9 21:49:45 PDT 2001 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102423a linux/net/ipv6/udp.c - 1.23 linux/net/ipv6/tcp_ipv6.c - 1.26 linux/net/ipv6/sit.c - 1.17 linux/net/ipv6/ip6_output.c - 1.11 linux/net/ipv6/icmp.c - 1.14 linux/net/ipv6/datagram.c - 1.9 linux/net/ipv6/addrconf.c - 1.21 linux/net/ipv4/udp.c - 1.25 linux/net/ipv4/tcp_ipv4.c - 1.34 linux/net/ipv4/ip_output.c - 1.27 linux/net/ipv4/ip_options.c - 1.6 linux/net/ipv4/ip_fragment.c - 1.15 linux/net/ipv4/icmp.c - 1.23 linux/net/ipv4/arp.c - 1.20 linux/include/asm-sparc64/system.h - 1.14 linux/include/asm-sparc64/pgtable.h - 1.23 linux/include/asm-sparc64/elf.h - 1.10 linux/fs/Config.in - 1.65 linux/drivers/sound/msnd_pinnacle.c - 1.18 linux/drivers/scsi/gdth_proc.h - 1.6 linux/drivers/scsi/gdth_proc.c - 1.12 linux/drivers/scsi/gdth_ioctl.h - 1.5 linux/drivers/scsi/gdth.h - 1.7 linux/drivers/scsi/gdth.c - 1.15 linux/drivers/isdn/isdn_audio.c - 1.9 linux/drivers/isdn/icn/icn.h - 1.9 linux/drivers/isdn/icn/icn.c - 1.15 linux/arch/sparc64/mm/ultra.S - 1.17 linux/arch/sparc64/mm/init.c - 1.31 linux/arch/sparc64/mm/fault.c - 1.19 linux/arch/sparc64/lib/blockops.S - 1.12 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.33 linux/arch/sparc64/kernel/ioctl32.c - 1.42 linux/arch/sparc64/kernel/head.S - 1.10 linux/drivers/isdn/hisax/isar.c - 1.14 linux/include/linux/telephony.h - 1.7 linux/drivers/telephony/ixj.h - 1.7 linux/drivers/telephony/ixj.c - 1.18 linux/drivers/usb/usb-uhci.c - 1.26 linux/drivers/ide/via82cxxx.c - 1.18 linux/drivers/usb/storage/transport.c - 1.12 linux/drivers/usb/storage/scsiglue.c - 1.13 linux/drivers/usb/storage/sddr09.c - 1.9 linux/drivers/usb/storage/unusual_devs.h - 1.6 linux/fs/freevxfs/vxfs_super.c - 1.4 linux/fs/freevxfs/vxfs_olt.c - 1.3 linux/fs/freevxfs/vxfs_inode.c - 1.5 linux/fs/freevxfs/vxfs_fshead.c - 1.3 linux/fs/freevxfs/vxfs_extern.h - 1.3 linux/fs/freevxfs/vxfs_bmap.c - 1.3 linux/drivers/bluetooth/hci_uart.c - 1.4 linux/include/net/bluetooth/bluetooth.h - 1.3 linux/include/net/bluetooth/bluez.h - 1.3 linux/include/net/bluetooth/hci.h - 1.3 linux/include/net/bluetooth/hci_core.h - 1.3 linux/include/net/bluetooth/hci_uart.h - 1.3 linux/include/net/bluetooth/hci_usb.h - 1.3 linux/include/net/bluetooth/l2cap.h - 1.3 linux/include/net/bluetooth/l2cap_core.h - 1.3 linux/drivers/bluetooth/hci_usb.c - 1.4 linux/net/bluetooth/af_bluetooth.c - 1.3 linux/net/bluetooth/hci_core.c - 1.3 linux/net/bluetooth/hci_sock.c - 1.3 linux/net/bluetooth/l2cap_core.c - 1.3 linux/net/bluetooth/l2cap_proc.c - 1.3 linux/net/bluetooth/lib.c - 1.3 linux/net/bluetooth/syms.c - 1.2 linux/drivers/message/fusion/scsi3.h - 1.3 linux/drivers/message/fusion/mptscsih.c - 1.3 linux/drivers/message/fusion/mptlan.c - 1.3 linux/drivers/message/fusion/mptctl.c - 1.4 linux/drivers/message/fusion/mptbase.h - 1.3 linux/drivers/message/fusion/mptbase.c - 1.3 linux/drivers/message/fusion/isense.c - 1.3 linux/drivers/message/fusion/lsi/fc_log.h - 1.3 linux/include/net/bluetooth/hci_vhci.h - 1.2 linux/drivers/video/sstfb.h - 1.2 linux/drivers/video/sstfb.c - 1.2 linux/Documentation/fb/README-sstfb.txt - 1.2 linux/drivers/bluetooth/hci_vhci.c - 1.2 From owner-linux-xfs@oss.sgi.com Sun Sep 9 21:56:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A4uFU04756 for linux-xfs-outgoing; Sun, 9 Sep 2001 21:56:15 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A4uAd04737; Sun, 9 Sep 2001 21:56:10 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8A4uBd04738 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Sun Sep 9 22:34:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A5Y2405183 for linux-xfs-outgoing; Sun, 9 Sep 2001 22:34:02 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A5Xtd05164; Sun, 9 Sep 2001 22:33:55 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8A5Xud05165 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Sun Sep 9 22:45:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A5jXo05405 for linux-xfs-outgoing; Sun, 9 Sep 2001 22:45:33 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A5jHd05380 for ; Sun, 9 Sep 2001 22:45:17 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA00241 for ; Sun, 9 Sep 2001 22:43:45 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id PAA08694; Mon, 10 Sep 2001 15:45:14 +1000 Date: Mon, 10 Sep 2001 15:45:14 +1000 From: Keith Owens Message-Id: <200109100545.PAA08694@sherman.melbourne.sgi.com> Subject: TAKE - Sync to 2.4.10-pre6 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sync to 2.4.10-pre6. This will not compile if ramdisk or quota are selected, due to bugs in the base 2.4.10-pre6 kernel. Date: Sun Sep 9 22:42:43 PDT 2001 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102424a linux/arch/sh/kernel/pcibios.c - 1.1 linux/arch/sh/kernel/rtc-aica.c - 1.1 linux/arch/sh/kernel/setup_7751se.c - 1.1 linux/arch/sh/kernel/setup_adx.c - 1.1 linux/arch/sh/lib/strlen.S - 1.1 linux/arch/sh/mm/__clear_user_page-sh4.S - 1.1 linux/arch/sh/mm/__copy_user_page-sh4.S - 1.1 linux/arch/sh/mm/cache-sh3.c - 1.1 linux/arch/sh/kernel/mach_adx.c - 1.1 linux/arch/ppc/8xx_io/micropatch.c - 1.1 linux/arch/sh/kernel/mach_7751se.c - 1.1 linux/arch/sh/mm/cache-sh4.c - 1.1 linux/arch/sh/kernel/led_7751se.c - 1.1 linux/arch/sh/kernel/irq_maskreg.c - 1.1 linux/include/asm-sh/io_adx.h - 1.1 linux/include/asm-sh/io_7751se.h - 1.1 linux/include/asm-sh/hitachi_7751se.h - 1.1 linux/arch/sh/mm/clear_page.S - 1.1 linux/include/asm-ppc/sections.h - 1.1 linux/include/asm-ppc/ppcboot.h - 1.1 linux/arch/sh/mm/copy_page.S - 1.1 linux/arch/sh/kernel/io_adx.c - 1.1 linux/arch/sh/kernel/io_7751se.c - 1.1 linux/arch/sh/kernel/dma.c - 1.1 linux/net/irda/af_irda.c - 1.23 linux/net/core/dev.c - 1.41 linux/mm/slab.c - 1.25 linux/kernel/softirq.c - 1.14 linux/include/linux/ntfs_fs_sb.h - 1.10 linux/include/linux/ntfs_fs_i.h - 1.8 linux/include/linux/ntfs_fs.h - 1.5 linux/include/linux/mc146818rtc.h - 1.6 linux/include/linux/interrupt.h - 1.16 linux/include/linux/genhd.h - 1.14 linux/include/linux/blkdev.h - 1.37 linux/include/asm-sparc64/softirq.h - 1.9 linux/include/asm-sparc/softirq.h - 1.10 linux/include/asm-ppc/softirq.h - 1.14 linux/include/asm-ppc/init.h - 1.11 linux/include/asm-i386/softirq.h - 1.13 linux/include/asm-i386/page.h - 1.18 linux/include/asm-arm/softirq.h - 1.8 linux/include/asm-alpha/softirq.h - 1.9 linux/fs/ntfs/util.h - 1.6 linux/fs/ntfs/support.h - 1.5 linux/fs/ntfs/support.c - 1.10 linux/fs/ntfs/super.h - 1.7 linux/fs/ntfs/super.c - 1.11 linux/fs/ntfs/struct.h - 1.7 linux/fs/ntfs/macros.h - 1.6 linux/fs/ntfs/inode.h - 1.5 linux/fs/ntfs/inode.c - 1.12 linux/fs/ntfs/fs.c - 1.30 linux/fs/ntfs/dir.c - 1.8 linux/fs/ntfs/attr.h - 1.5 linux/fs/ntfs/attr.c - 1.7 linux/fs/ntfs/Makefile - 1.11 linux/drivers/scsi/sd.c - 1.42 linux/drivers/net/smc9194.h - 1.4 linux/drivers/net/smc9194.c - 1.16 linux/drivers/macintosh/via-pmu.c - 1.16 linux/drivers/macintosh/mediabay.c - 1.12 linux/drivers/macintosh/macserial.c - 1.18 linux/drivers/block/xd.c - 1.20 linux/drivers/block/ps2esdi.c - 1.19 linux/drivers/block/paride/pd.c - 1.15 linux/drivers/block/ll_rw_blk.c - 1.74 linux/drivers/block/genhd.c - 1.17 linux/drivers/block/acsi.c - 1.14 linux/drivers/acorn/block/mfmhd.c - 1.11 linux/arch/ppc/kernel/smp.c - 1.27 linux/arch/ppc/kernel/setup.c - 1.35 linux/arch/ppc/kernel/residual.c - 1.7 linux/arch/ppc/kernel/prom.c - 1.26 linux/arch/ppc/kernel/prep_time.c - 1.7 linux/arch/ppc/kernel/prep_setup.c - 1.24 linux/arch/ppc/kernel/prep_pci.c - 1.13 linux/arch/ppc/kernel/prep_nvram.c - 1.8 linux/arch/ppc/kernel/pmac_time.c - 1.14 linux/arch/ppc/kernel/pmac_setup.c - 1.25 linux/arch/ppc/kernel/pmac_pic.c - 1.20 linux/arch/ppc/kernel/pmac_pci.c - 1.18 linux/arch/ppc/kernel/open_pic.c - 1.20 linux/arch/ppc/kernel/indirect_pci.c - 1.6 linux/arch/ppc/kernel/feature.c - 1.15 linux/arch/ppc/kernel/chrp_time.c - 1.10 linux/arch/ppc/kernel/chrp_setup.c - 1.26 linux/arch/ppc/kernel/chrp_pci.c - 1.19 linux/arch/ppc/kernel/apus_setup.c - 1.18 linux/arch/ppc/8xx_io/Makefile - 1.6 linux/arch/i386/kernel/setup.c - 1.52 linux/arch/i386/kernel/entry.S - 1.35 linux/Makefile - 1.119 linux/Documentation/filesystems/ntfs.txt - 1.9 linux/Documentation/Configure.help - 1.97 linux/drivers/i2o/i2o_block.c - 1.27 linux/drivers/block/blkpg.c - 1.10 linux/drivers/block/cpqarray.c - 1.26 linux/fs/partitions/check.c - 1.30 linux/drivers/block/DAC960.c - 1.34 linux/arch/sh/vmlinux.lds.S - 1.12 linux/arch/sh/mm/ioremap.c - 1.7 linux/arch/sh/mm/init.c - 1.15 linux/arch/sh/mm/fault.c - 1.16 linux/arch/sh/mm/extable.c - 1.4 linux/arch/sh/mm/Makefile - 1.5 linux/arch/sh/lib/Makefile - 1.7 linux/arch/sh/kernel/traps.c - 1.10 linux/arch/sh/kernel/time.c - 1.16 linux/arch/sh/kernel/sys_sh.c - 1.8 linux/arch/sh/kernel/sh_ksyms.c - 1.10 linux/arch/sh/kernel/setup.c - 1.16 linux/arch/sh/kernel/ptrace.c - 1.10 linux/arch/sh/kernel/process.c - 1.14 linux/arch/sh/kernel/irq.c - 1.12 linux/arch/sh/kernel/entry.S - 1.19 linux/arch/sh/kernel/Makefile - 1.13 linux/arch/sh/config.in - 1.18 linux/arch/sh/Makefile - 1.7 linux/include/asm-sh/uaccess.h - 1.9 linux/include/asm-sh/system.h - 1.11 linux/include/asm-sh/string.h - 1.7 linux/include/asm-sh/softirq.h - 1.9 linux/include/asm-sh/shmparam.h - 1.3 linux/include/asm-sh/semaphore.h - 1.6 linux/include/asm-sh/ptrace.h - 1.7 linux/include/asm-sh/processor.h - 1.14 linux/include/asm-sh/pgtable.h - 1.19 linux/include/asm-sh/page.h - 1.11 linux/include/asm-sh/mmu_context.h - 1.10 linux/include/asm-sh/irq.h - 1.11 linux/include/asm-sh/io.h - 1.11 linux/include/asm-sh/hardirq.h - 1.8 linux/include/asm-sh/elf.h - 1.7 linux/include/asm-sh/dma.h - 1.5 linux/include/asm-sh/checksum.h - 1.8 linux/include/asm-sh/cache.h - 1.5 linux/include/asm-sh/atomic.h - 1.5 linux/arch/ppc/kernel/m8xx_setup.c - 1.16 linux/arch/ppc/8xx_io/Config.in - 1.5 linux/drivers/net/wan/sdla_x25.c - 1.10 linux/drivers/net/wan/sdla_ppp.c - 1.13 linux/drivers/net/wan/sdla_fr.c - 1.14 linux/arch/sh/mm/cache.c - 1.13 linux/arch/sh/lib/checksum.S - 1.7 linux/include/asm-sh/smplock.h - 1.3 linux/include/asm-sh/ide.h - 1.9 linux/include/asm-sh/pgtable-2level.h - 1.7 linux/arch/ppc/kernel/pmac_nvram.c - 1.10 linux/drivers/net/wan/sdla_chdlc.c - 1.12 linux/include/linux/raid/md.h - 1.8 linux/include/asm-ia64/softirq.h - 1.6 linux/include/asm-sh/pgalloc.h - 1.5 linux/include/asm-sh/pci.h - 1.9 linux/drivers/char/sh-sci.c - 1.13 linux/arch/sh/kernel/irq_imask.c - 1.7 linux/arch/sh/kernel/cf-enabler.c - 1.5 linux/drivers/ide/ide.c - 1.28 linux/drivers/ide/ide-probe.c - 1.16 linux/drivers/ide/hd.c - 1.10 linux/include/asm-s390/softirq.h - 1.5 linux/drivers/s390/block/dasd.c - 1.11 linux/arch/sh/kernel/irq_ipr.c - 1.6 linux/include/asm-sh/hd64461.h - 1.4 linux/include/asm-sh/keyboard.h - 1.4 linux/include/asm-sh/linux_logo.h - 1.3 linux/drivers/acpi/Makefile - 1.8 linux/drivers/mtd/ftl.c - 1.6 linux/arch/sh/kernel/setup_hd64461.c - 1.4 linux/arch/ppc/kernel/pmac_backlight.c - 1.4 linux/include/asm-sh/machvec.h - 1.4 linux/arch/sh/kernel/setup_cqreek.c - 1.4 linux/arch/sh/kernel/mach_hp600.c - 1.3 linux/arch/sh/kernel/led_se.c - 1.2 linux/drivers/md/lvm.c - 1.17 linux/arch/i386/kernel/bluesmoke.c - 1.12 linux/drivers/block/cciss.c - 1.13 linux/drivers/macintosh/rtc.c - 1.4 linux/drivers/md/md.c - 1.21 linux/drivers/atm/firestream.c - 1.5 linux/drivers/atm/firestream.h - 1.4 linux/fs/reiserfs/stree.c - 1.7 linux/fs/reiserfs/super.c - 1.7 linux/fs/reiserfs/tail_conversion.c - 1.5 linux/fs/reiserfs/resize.c - 1.2 linux/fs/reiserfs/prints.c - 1.4 linux/fs/reiserfs/objectid.c - 1.3 linux/fs/reiserfs/namei.c - 1.6 linux/fs/reiserfs/lbalance.c - 1.2 linux/fs/reiserfs/journal.c - 1.7 linux/fs/reiserfs/item_ops.c - 1.2 linux/fs/reiserfs/ioctl.c - 1.3 linux/fs/reiserfs/inode.c - 1.10 linux/fs/reiserfs/ibalance.c - 1.2 linux/fs/reiserfs/hashes.c - 1.2 linux/fs/reiserfs/fix_node.c - 1.7 linux/fs/reiserfs/file.c - 1.3 linux/fs/reiserfs/do_balan.c - 1.3 linux/fs/reiserfs/dir.c - 1.5 linux/fs/reiserfs/buffer2.c - 1.2 linux/include/linux/reiserfs_fs.h - 1.8 linux/fs/reiserfs/bitmap.c - 1.4 linux/include/asm-s390x/softirq.h - 1.4 linux/include/asm-cris/softirq.h - 1.3 linux/include/asm-ppc/tqm8xx.h - 1.5 linux/drivers/net/wan/sdla_ft1.c - 1.3 linux/drivers/net/wan/wanpipe_multppp.c - 1.5 linux/arch/sh/kernel/setup_hd64465.c - 1.2 linux/arch/sh/kernel/setup_ec3104.c - 1.3 linux/arch/sh/kernel/setup_dc.c - 1.4 linux/arch/sh/kernel/pci_st40.c - 1.3 linux/arch/sh/kernel/mach_dc.c - 1.4 linux/arch/sh/kernel/irq_intc2.c - 1.4 linux/drivers/net/irda/irda-usb.c - 1.4 linux/arch/ppc/kernel/apus_pci.c - 1.3 linux/drivers/mtd/nftlcore.c - 1.2 linux/arch/sh/kernel/setup_bigsur.c - 1.2 linux/arch/sh/kernel/pci-sh7751.c - 1.2 linux/arch/sh/kernel/pci-dma.c - 1.2 linux/arch/sh/kernel/pci-dc.c - 1.2 linux/arch/sh/kernel/pci-7751se.c - 1.2 linux/Documentation/DocBook/procfs-guide.tmpl - 1.2 linux/drivers/net/wan/farsync.c - 1.2 linux/arch/ppc/kernel/pmac_smp.c - 1.2 linux/arch/ppc/kernel/chrp_smp.c - 1.2 linux/arch/ppc/kernel/btext.c - 1.2 From owner-linux-xfs@oss.sgi.com Sun Sep 9 23:40:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A6eAD06407 for linux-xfs-outgoing; Sun, 9 Sep 2001 23:40:10 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A6dVd06383 for ; Sun, 9 Sep 2001 23:39:32 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8A6dP511990 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Sun, 9 Sep 2001 23:39:25 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id IAA212469 for ; Mon, 10 Sep 2001 08:39:31 +0200 (CEST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id QAA21231; Mon, 10 Sep 2001 16:39:05 +1000 Date: Mon, 10 Sep 2001 16:39:05 +1000 From: Keith Owens Message-Id: <200109100639.QAA21231@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade to 2.4.10-pre7 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Upgrade to 2.4.10-pre7. Ramdisk and quota should compile again. Date: Sun Sep 9 23:34:52 PDT 2001 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102429a linux/include/asm-mips/ddb5xxx/pci.h - 1.1 linux/arch/mips64/sgi-ip32/ip32-timer.c - 1.1 linux/arch/mips64/mips-boards/atlas/atlas_setup.c - 1.1 linux/arch/mips64/sgi-ip32/ip32-setup.c - 1.1 linux/arch/mips64/sgi-ip32/ip32-rtc.c - 1.1 linux/arch/mips64/sgi-ip32/ip32-pci.c - 1.1 linux/arch/mips64/sgi-ip32/ip32-pci-dma.c - 1.1 linux/arch/mips64/sgi-ip32/ip32-irq.c - 1.1 linux/arch/mips64/sgi-ip32/ip32-irq-glue.S - 1.1 linux/arch/mips/au1000/common/Makefile - 1.1 linux/arch/mips/au1000/common/dbg_io.c - 1.1 linux/arch/mips/au1000/common/int-handler.S - 1.1 linux/arch/mips/au1000/common/irq.c - 1.1 linux/arch/mips/au1000/common/prom.c - 1.1 linux/arch/mips/au1000/common/puts.c - 1.1 linux/arch/mips/au1000/common/reset.c - 1.1 linux/arch/mips/au1000/common/serial.c - 1.1 linux/arch/mips/au1000/common/time.c - 1.1 linux/arch/mips/au1000/pb1000/Makefile - 1.1 linux/arch/mips/au1000/pb1000/init.c - 1.1 linux/arch/mips/au1000/pb1000/setup.c - 1.1 linux/include/asm-mips/mips-boards/saa9730_uart.h - 1.1 linux/arch/mips64/mips-boards/generic/pci.c - 1.1 linux/include/asm-mips/linux_logo_dec.h - 1.1 linux/arch/mips/ite-boards/ivr/Makefile - 1.1 linux/include/asm-mips64/tlb.h - 1.1 linux/arch/mips64/sgi-ip32/ip32-berr.c - 1.1 linux/arch/mips64/sgi-ip32/crime.c - 1.1 linux/arch/mips64/sgi-ip32/Makefile - 1.1 linux/include/asm-mips64/mips-boards/saa9730_uart.h - 1.1 linux/include/asm-mips64/mips-boards/prom.h - 1.1 linux/include/asm-mips64/mips-boards/piix4.h - 1.1 linux/include/asm-mips64/mips-boards/maltaint.h - 1.1 linux/arch/mips/ddb5xxx/common/Makefile - 1.1 linux/arch/mips/ddb5xxx/common/irq.c - 1.1 linux/arch/mips/ddb5xxx/common/irq_cpu.c - 1.1 linux/arch/mips/ddb5xxx/common/nile4.c - 1.1 linux/arch/mips/ddb5xxx/common/pci.c - 1.1 linux/arch/mips/ddb5xxx/common/pci_auto.c - 1.1 linux/arch/mips/ddb5xxx/common/prom.c - 1.1 linux/arch/mips/ddb5xxx/common/rtc_ds1386.c - 1.1 linux/arch/mips/ddb5xxx/ddb5477/Makefile - 1.1 linux/arch/mips/ddb5xxx/ddb5477/debug.c - 1.1 linux/arch/mips/ddb5xxx/ddb5477/int-handler.S - 1.1 linux/arch/mips/ddb5xxx/ddb5477/irq.c - 1.1 linux/arch/mips/ddb5xxx/ddb5477/irq_5477.c - 1.1 linux/arch/mips/ddb5xxx/ddb5477/kgdb_io.c - 1.1 linux/arch/mips/ddb5xxx/ddb5477/pci.c - 1.1 linux/arch/mips/ddb5xxx/ddb5477/pci_ops.c - 1.1 linux/arch/mips/ddb5xxx/ddb5477/setup.c - 1.1 linux/include/asm-mips64/mips-boards/malta.h - 1.1 linux/include/asm-mips64/mips-boards/io.h - 1.1 linux/include/asm-mips64/mips-boards/gt64120.h - 1.1 linux/include/asm-mips64/mips-boards/generic.h - 1.1 linux/include/asm-mips64/mips-boards/atlasint.h - 1.1 linux/include/asm-mips64/mips-boards/atlas.h - 1.1 linux/arch/mips64/mips-boards/generic/printf.c - 1.1 linux/arch/mips64/mips-boards/generic/reset.c - 1.1 linux/arch/mips64/mips-boards/generic/time.c - 1.1 linux/arch/mips/philips/nino/time.c - 1.1 linux/arch/mips/philips/nino/setup.c - 1.1 linux/arch/mips64/mips-boards/atlas/atlas_rtc.c - 1.1 linux/arch/mips/defconfig-atlas - 1.1 linux/arch/mips/philips/nino/rtc.c - 1.1 linux/arch/mips/philips/nino/reset.c - 1.1 linux/arch/mips/defconfig-ddb5477 - 1.1 linux/arch/mips/philips/nino/ramdisk/ld.script - 1.1 linux/arch/mips/philips/nino/ramdisk/Makefile - 1.1 linux/arch/mips/philips/nino/prom.c - 1.1 linux/arch/mips/defconfig-malta - 1.1 linux/arch/mips/defconfig-nino - 1.1 linux/arch/mips/defconfig-ocelot - 1.1 linux/arch/mips/philips/nino/power.c - 1.1 linux/arch/mips/defconfig-pb1000 - 1.1 linux/include/asm-mips/pci_channel.h - 1.1 linux/arch/mips/gt64120/common/Makefile - 1.1 linux/arch/mips/gt64120/common/gt_irq.c - 1.1 linux/arch/mips/gt64120/common/pci.c - 1.1 linux/arch/mips/gt64120/momenco_ocelot/Makefile - 1.1 linux/arch/mips/gt64120/momenco_ocelot/dbg_io.c - 1.1 linux/arch/mips/gt64120/momenco_ocelot/int-handler.S - 1.1 linux/arch/mips/gt64120/momenco_ocelot/irq.c - 1.1 linux/arch/mips/gt64120/momenco_ocelot/ocelot_pld.h - 1.1 linux/arch/mips/gt64120/momenco_ocelot/pci.c - 1.1 linux/arch/mips/gt64120/momenco_ocelot/prom.c - 1.1 linux/arch/mips/gt64120/momenco_ocelot/reset.c - 1.1 linux/arch/mips/gt64120/momenco_ocelot/setup.c - 1.1 linux/arch/mips/philips/nino/kgdb.c - 1.1 linux/arch/mips/philips/nino/irq.c - 1.1 linux/include/asm-mips/mips-boards/prom.h - 1.1 linux/arch/mips64/mips-boards/malta/malta_int.c - 1.1 linux/include/asm-mips/mips-boards/piix4.h - 1.1 linux/include/asm-mips/mips-boards/maltaint.h - 1.1 linux/include/asm-mips/mips-boards/malta.h - 1.1 linux/include/asm-mips/mips-boards/generic.h - 1.1 linux/include/asm-mips/mips-boards/atlasint.h - 1.1 linux/include/asm-mips/mips-boards/atlas.h - 1.1 linux/include/asm-mips/linux_logo_sgi.h - 1.1 linux/arch/mips/kernel/pci_auto.c - 1.1 linux/arch/mips/philips/nino/int-handler.S - 1.1 linux/arch/mips/ite-boards/ivr/README - 1.1 linux/arch/mips/ite-boards/ivr/init.c - 1.1 linux/arch/mips/ite-boards/ivr/pci_fixup.c - 1.1 linux/arch/mips/philips/nino/Makefile - 1.1 linux/arch/mips64/mips-boards/generic/mipsIRQ.S - 1.1 linux/arch/mips64/mips-boards/malta/Makefile - 1.1 linux/arch/mips/jazz/irq.c - 1.1 linux/arch/mips64/mips-boards/atlas/atlas_int.c - 1.1 linux/arch/mips64/mips-boards/atlas/Makefile - 1.1 linux/drivers/isdn/hisax/hisax_if.h - 1.1 linux/drivers/isdn/hisax/st5481.h - 1.1 linux/drivers/isdn/hisax/st5481_b.c - 1.1 linux/drivers/isdn/hisax/st5481_d.c - 1.1 linux/drivers/isdn/hisax/st5481_hdlc.c - 1.1 linux/drivers/isdn/hisax/st5481_hdlc.h - 1.1 linux/drivers/isdn/hisax/st5481_init.c - 1.1 linux/drivers/isdn/hisax/st5481_usb.c - 1.1 linux/drivers/scsi/README.53c700 - 1.1 linux/drivers/net/ns83820.c - 1.1 linux/drivers/scsi/53c700-mem.c - 1.1 linux/drivers/scsi/53c700.c - 1.1 linux/drivers/scsi/53c700.h - 1.1 linux/drivers/scsi/53c700.scr - 1.1 linux/arch/mips64/mips-boards/generic/cmdline.c - 1.1 linux/drivers/scsi/NCR_D700.c - 1.1 linux/drivers/char/decserial.c - 1.1 linux/drivers/scsi/NCR_D700.h - 1.1 linux/drivers/char/ite_gpio.c - 1.1 linux/include/asm-mips/gt64120/gt64120.h - 1.1 linux/drivers/scsi/README.dpti - 1.1 linux/drivers/i2c/i2c-adap-ite.c - 1.1 linux/drivers/i2c/i2c-algo-ite.c - 1.1 linux/drivers/i2c/i2c-ite.h - 1.1 linux/arch/mips64/defconfig-ip32 - 1.1 linux/drivers/scsi/lasi700.c - 1.1 linux/drivers/scsi/lasi700.h - 1.1 linux/arch/mips64/mips-boards/generic/Makefile - 1.1 linux/include/asm-mips/gcc/sgidefs.h - 1.1 linux/arch/mips/sni/irq.c - 1.1 linux/drivers/isdn/hisax/fsm.h - 1.1 linux/include/asm-mips/ddb5xxx/debug.h - 1.1 linux/include/asm-mips/gt64120/momenco_ocelot/gt64120_dep.h - 1.1 linux/include/asm-mips/gt64120.h - 1.1 linux/include/asm-mips/ddb5xxx/ddb5477.h - 1.1 linux/arch/mips64/mips-boards/generic/display.c - 1.1 linux/include/asm-mips/dec/ioasic.h - 1.1 linux/arch/mips64/mips-boards/generic/gdb_hook.c - 1.1 linux/arch/mips64/mips-boards/generic/init.c - 1.1 linux/include/asm-mips/ddb5xxx/ddb5xxx.h - 1.1 linux/drivers/isdn/hisax/hisax_debug.h - 1.1 linux/arch/mips64/mips-boards/malta/malta_setup.c - 1.1 linux/arch/mips64/mips-boards/generic/memory.c - 1.1 linux/include/asm-mips/au1000.h - 1.1 linux/arch/mips64/mips-boards/malta/malta_rtc.c - 1.1 linux/net/ax25/ax25_in.c - 1.10 linux/kernel/ksyms.c - 1.105 linux/include/linux/soundcard.h - 1.6 linux/include/linux/module.h - 1.21 linux/include/linux/isdn.h - 1.18 linux/include/asm-mips/uaccess.h - 1.8 linux/include/asm-mips/termios.h - 1.10 linux/include/asm-mips/termbits.h - 1.3 linux/include/asm-mips/system.h - 1.10 linux/include/asm-mips/string.h - 1.6 linux/include/asm-mips/softirq.h - 1.6 linux/include/asm-mips/sgidefs.h - 1.3 linux/include/asm-mips/semaphore.h - 1.9 linux/include/asm-mips/reboot.h - 1.4 linux/include/asm-mips/processor.h - 1.16 linux/include/asm-mips/pgtable.h - 1.14 linux/include/asm-mips/pci.h - 1.11 linux/include/asm-mips/mipsregs.h - 1.9 linux/include/asm-mips/linux_logo.h - 1.6 linux/include/asm-mips/keyboard.h - 1.9 linux/include/asm-mips/irq.h - 1.7 linux/include/asm-mips/ioctls.h - 1.6 linux/include/asm-mips/io.h - 1.8 linux/include/asm-mips/ide.h - 1.9 linux/include/asm-mips/hardirq.h - 1.10 linux/include/asm-mips/elf.h - 1.10 linux/include/asm-mips/cpu.h - 1.6 linux/include/asm-mips/cachectl.h - 1.3 linux/include/asm-mips/bootinfo.h - 1.10 linux/include/asm-mips/bitops.h - 1.8 linux/include/asm-mips/atomic.h - 1.8 linux/include/asm-mips/asm.h - 1.4 linux/fs/super.c - 1.53 linux/fs/ntfs/support.h - 1.6 linux/fs/minix/file.c - 1.12 linux/fs/dquot.c - 1.36 linux/drivers/sound/sound_core.c - 1.18 linux/drivers/sound/opl3sa2.c - 1.9 linux/drivers/scsi/sgiwd93.c - 1.11 linux/drivers/scsi/sd.c - 1.43 linux/drivers/scsi/scsi_error.c - 1.20 linux/drivers/scsi/megaraid.c - 1.26 linux/drivers/scsi/Makefile - 1.27 linux/drivers/scsi/Config.in - 1.23 linux/drivers/pci/Makefile - 1.17 linux/drivers/net/pcnet32.c - 1.25 linux/drivers/net/dgrs.c - 1.18 linux/drivers/net/cs89x0.c - 1.19 linux/drivers/isdn/isdnloop/isdnloop.h - 1.7 linux/drivers/isdn/isdnloop/isdnloop.c - 1.8 linux/drivers/isdn/isdn_tty.h - 1.9 linux/drivers/isdn/isdn_tty.c - 1.16 linux/drivers/isdn/isdn_net.h - 1.9 linux/drivers/isdn/isdn_net.c - 1.23 linux/drivers/isdn/isdn_common.c - 1.27 linux/drivers/isdn/hisax/isdnl1.h - 1.5 linux/drivers/isdn/hisax/isdnl1.c - 1.13 linux/drivers/isdn/hisax/hisax.h - 1.21 linux/drivers/isdn/hisax/fsm.c - 1.9 linux/drivers/isdn/hisax/config.c - 1.23 linux/drivers/isdn/hisax/callc.c - 1.14 linux/drivers/isdn/hisax/Makefile - 1.13 linux/drivers/isdn/act2000/act2000_isa.c - 1.6 linux/drivers/isdn/Config.in - 1.19 linux/drivers/char/rtc.c - 1.22 linux/drivers/char/mem.c - 1.38 linux/drivers/char/epca.c - 1.17 linux/drivers/char/Makefile - 1.48 linux/drivers/char/Config.in - 1.47 linux/drivers/cdrom/sonycd535.c - 1.13 linux/drivers/cdrom/sbpcd.c - 1.14 linux/drivers/cdrom/optcd.c - 1.12 linux/drivers/cdrom/mcd.h - 1.4 linux/drivers/cdrom/mcd.c - 1.12 linux/drivers/cdrom/aztcd.c - 1.13 linux/drivers/block/xd.c - 1.21 linux/drivers/block/rd.c - 1.32 linux/drivers/block/ps2esdi.c - 1.20 linux/drivers/block/paride/pd.c - 1.16 linux/drivers/block/genhd.c - 1.18 linux/drivers/block/acsi.c - 1.15 linux/drivers/block/Makefile - 1.22 linux/drivers/acorn/block/mfmhd.c - 1.12 linux/arch/mips/sni/setup.c - 1.9 linux/arch/mips/sni/pci.c - 1.9 linux/arch/mips/sni/int-handler.S - 1.6 linux/arch/mips/sgi/kernel/time.c - 1.8 linux/arch/mips/sgi/kernel/setup.c - 1.10 linux/arch/mips/sgi/kernel/reset.c - 1.7 linux/arch/mips/sgi/kernel/indy_timer.c - 1.9 linux/arch/mips/sgi/kernel/indy_sc.c - 1.9 linux/arch/mips/sgi/kernel/indy_rtc.c - 1.5 linux/arch/mips/sgi/kernel/indy_int.c - 1.10 linux/arch/mips/sgi/kernel/indy_hpc.c - 1.7 linux/arch/mips/mm/r4xx0.c - 1.9 linux/arch/mips/mm/r2300.c - 1.10 linux/arch/mips/mm/loadmmu.c - 1.9 linux/arch/mips/mm/andes.c - 1.9 linux/arch/mips/mm/Makefile - 1.7 linux/arch/mips/lib/memcpy.S - 1.7 linux/arch/mips/lib/ide-std.c - 1.5 linux/arch/mips/kernel/unaligned.c - 1.7 linux/arch/mips/kernel/traps.c - 1.11 linux/arch/mips/kernel/time.c - 1.11 linux/arch/mips/kernel/softfp.S - 1.6 linux/arch/mips/kernel/signal.c - 1.13 linux/arch/mips/kernel/setup.c - 1.12 linux/arch/mips/kernel/scall_o32.S - 1.9 linux/arch/mips/kernel/reset.c - 1.3 linux/arch/mips/kernel/r4k_switch.S - 1.8 linux/arch/mips/kernel/r2300_switch.S - 1.8 linux/arch/mips/kernel/ptrace.c - 1.12 linux/arch/mips/kernel/process.c - 1.12 linux/arch/mips/kernel/proc.c - 1.6 linux/arch/mips/kernel/pci.c - 1.7 linux/arch/mips/kernel/mips_ksyms.c - 1.11 linux/arch/mips/kernel/irq.c - 1.11 linux/arch/mips/kernel/head.S - 1.10 linux/arch/mips/kernel/gdb-stub.c - 1.7 linux/arch/mips/kernel/gdb-low.S - 1.6 linux/arch/mips/kernel/fpe.c - 1.6 linux/arch/mips/kernel/entry.S - 1.8 linux/arch/mips/kernel/branch.c - 1.4 linux/arch/mips/kernel/Makefile - 1.8 linux/arch/mips/jazz/setup.c - 1.7 linux/arch/mips/jazz/rtc-jazz.c - 1.6 linux/arch/mips/jazz/jazzdma.c - 1.5 linux/arch/mips/defconfig - 1.19 linux/arch/mips/config.in - 1.23 linux/arch/mips/boot/mkboot.c - 1.4 linux/arch/mips/boot/Makefile - 1.7 linux/arch/mips/Makefile - 1.10 linux/arch/i386/kernel/setup.c - 1.53 linux/arch/i386/defconfig - 1.67 linux/Makefile - 1.120 linux/MAINTAINERS - 1.71 linux/Documentation/isdn/README - 1.7 linux/Documentation/CodingStyle - 1.4 linux/CREDITS - 1.60 linux/drivers/net/irda/toshoboe.c - 1.24 linux/drivers/isdn/hisax/elsa_ser.c - 1.9 linux/drivers/i2o/i2o_block.c - 1.28 linux/include/asm-mips/semaphore-helper.h - 1.6 linux/include/asm-mips/dec/tcmodule.h - 1.2 linux/include/asm-mips/dec/kn03.h - 1.2 linux/include/asm-mips/dec/kn02xa.h - 1.2 linux/include/asm-mips/dec/kn02.h - 1.2 linux/include/asm-mips/dec/ioasic_addrs.h - 1.2 linux/include/asm-mips/dec/interrupts.h - 1.2 linux/drivers/net/jazzsonic.c - 1.8 linux/drivers/net/declance.c - 1.12 linux/drivers/char/dz.c - 1.13 linux/arch/mips/sgi/kernel/promcon.c - 1.5 linux/arch/mips/dec/time.c - 1.6 linux/arch/mips/dec/setup.c - 1.4 linux/arch/mips/dec/serial.c - 1.5 linux/arch/mips/dec/rtc-dec.c - 1.4 linux/arch/mips/dec/reset.c - 1.3 linux/arch/mips/dec/prom/memory.c - 1.8 linux/arch/mips/dec/prom/init.c - 1.5 linux/arch/mips/dec/prom/cmdline.c - 1.5 linux/arch/mips/dec/irq.c - 1.7 linux/arch/mips/dec/int-handler.S - 1.2 linux/arch/mips/dec/Makefile - 1.4 linux/arch/mips/baget/vacserial.c - 1.10 linux/arch/mips/baget/time.c - 1.5 linux/arch/mips/baget/setup.c - 1.5 linux/arch/mips/baget/prom/init.c - 1.5 linux/arch/mips/baget/irq.c - 1.8 linux/drivers/net/ppp_generic.c - 1.22 linux/drivers/isdn/isdn_ttyfax.c - 1.6 linux/drivers/net/sis900.c - 1.26 linux/drivers/block/DAC960.c - 1.35 linux/drivers/net/dmfe.c - 1.19 linux/include/linux/pci_ids.h - 1.44 linux/drivers/net/wan/z85230.c - 1.10 linux/drivers/net/wan/sealevel.c - 1.9 linux/drivers/net/wan/sbni.c - 1.14 linux/drivers/net/wan/hostess_sv11.c - 1.9 linux/drivers/scsi/dec_esp.c - 1.6 linux/drivers/net/sk98lin/h/skdrv1st.h - 1.6 linux/drivers/telephony/ixj.c - 1.19 linux/drivers/char/moxa.c - 1.8 linux/drivers/sound/via82cxxx_audio.c - 1.20 linux/arch/mips/ddb5074/pci.c - 1.7 linux/arch/mips/defconfig-decstation - 1.7 linux/arch/mips/defconfig-ip22 - 1.8 linux/drivers/net/tulip/tulip_core.c - 1.27 linux/include/asm-mips64/ioctl.h - 1.4 linux/include/asm-mips64/io.h - 1.6 linux/include/asm-mips64/inst.h - 1.3 linux/include/asm-mips64/init.h - 1.4 linux/include/asm-mips64/ide.h - 1.6 linux/include/asm-mips64/hardirq.h - 1.5 linux/include/asm-mips64/gfx.h - 1.3 linux/include/asm-mips64/fcntl.h - 1.7 linux/include/asm-mips64/elf.h - 1.7 linux/include/asm-mips64/ds1286.h - 1.3 linux/include/asm-mips64/div64.h - 1.3 linux/include/asm-mips64/current.h - 1.3 linux/include/asm-mips64/cachectl.h - 1.2 linux/include/asm-mips64/byteorder.h - 1.3 linux/include/asm-mips64/bugs.h - 1.3 linux/include/asm-mips64/branch.h - 1.3 linux/include/asm-mips64/bootinfo.h - 1.5 linux/include/asm-mips64/bitops.h - 1.6 linux/include/asm-mips64/bcache.h - 1.4 linux/include/asm-mips64/asmmacro.h - 1.3 linux/include/asm-mips64/asm.h - 1.3 linux/include/asm-mips64/arc/hinv.h - 1.3 linux/include/asm-mips64/addrspace.h - 1.4 linux/include/asm-mips64/a.out.h - 1.3 linux/include/asm-mips/isadep.h - 1.3 linux/include/asm-mips/div64.h - 1.4 linux/include/asm-mips64/sn/sn0/ip27.h - 1.5 linux/include/asm-mips64/sn/sn0/addrs.h - 1.3 linux/include/asm-mips64/sn/klconfig.h - 1.4 linux/include/asm-mips64/sn/gda.h - 1.3 linux/include/asm-mips64/sn/arch.h - 1.4 linux/include/asm-mips64/signal.h - 1.3 linux/include/asm-mips64/xtalk/xwidget.h - 1.3 linux/include/asm-mips64/sigcontext.h - 1.3 linux/include/asm-mips64/shmparam.h - 1.3 linux/include/asm-mips64/shmiq.h - 1.4 linux/include/asm-mips64/sgidefs.h - 1.3 linux/include/asm-mips64/xtalk/xtalk.h - 1.3 linux/include/asm-mips64/sgiarcs.h - 1.4 linux/include/asm-mips64/sgialib.h - 1.4 linux/include/asm-mips64/sgi/sgint23.h - 1.5 linux/include/asm-mips64/sgi/sgimc.h - 1.3 linux/include/asm-mips64/sgi/sgihpc.h - 1.3 linux/include/asm-mips64/usioctl.h - 1.3 linux/include/asm-mips64/sgi/sgi.h - 1.3 linux/include/asm-mips64/sgi/io.h - 1.3 linux/include/asm-mips64/serial.h - 1.5 linux/include/asm-mips64/user.h - 1.3 linux/include/asm-mips64/resource.h - 1.6 linux/include/asm-mips64/regdef.h - 1.3 linux/include/asm-mips64/r4kcacheops.h - 1.3 linux/include/asm-mips64/r4kcache.h - 1.3 linux/include/asm-mips64/r10kcacheops.h - 1.3 linux/include/asm-mips64/r10kcache.h - 1.3 linux/include/asm-mips64/ucontext.h - 1.3 linux/include/asm-mips64/poll.h - 1.3 linux/include/asm-mips64/pgtable.h - 1.9 linux/include/asm-mips64/uaccess.h - 1.5 linux/include/asm-mips64/pci/bridge.h - 1.4 linux/include/asm-mips64/pci.h - 1.7 linux/include/asm-mips64/parport.h - 1.4 linux/include/asm-mips64/types.h - 1.3 linux/include/asm-mips64/paccess.h - 1.3 linux/include/asm-mips64/timex.h - 1.3 linux/include/asm-mips64/termios.h - 1.6 linux/include/asm-mips64/termbits.h - 1.3 linux/include/asm-mips64/sysmips.h - 1.3 linux/include/asm-mips64/statfs.h - 1.3 linux/include/asm-mips64/softirq.h - 1.3 linux/include/asm-mips64/sockios.h - 1.3 linux/include/asm-mips64/sn/types.h - 1.5 linux/include/asm-mips64/sn/sn0/sn0_fru.h - 1.3 linux/include/asm-mips64/ng1.h - 1.3 linux/include/asm-mips64/namei.h - 1.4 linux/include/asm-mips64/sn/sn0/hubpi.h - 1.3 linux/include/asm-mips64/ioctls.h - 1.5 linux/include/asm-mips64/mmu_context.h - 1.6 linux/include/asm-mips64/sn/sn0/hubni.h - 1.3 linux/include/asm-mips64/sn/sn0/hub.h - 1.3 linux/include/asm-mips64/sn/sn0/hubmd.h - 1.3 linux/include/asm-mips64/sn/sn0/arch.h - 1.3 linux/include/asm-mips64/sn/sn0/hubio.h - 1.3 linux/include/asm-mips64/keyboard.h - 1.4 linux/include/asm-mips64/linux_logo.h - 1.4 linux/include/asm-mips64/mman.h - 1.3 linux/include/asm-mips64/mipsregs.h - 1.7 linux/include/asm-mips64/mc146818rtc.h - 1.4 linux/arch/mips64/defconfig - 1.15 linux/arch/mips64/sgi-ip22/ip22-rtc.c - 1.3 linux/arch/mips64/arc/env.c - 1.3 linux/arch/mips64/sgi-ip22/ip22-reset.c - 1.4 linux/arch/mips64/sgi-ip22/ip22-int.c - 1.6 linux/arch/mips64/sgi-ip22/ip22-mc.c - 1.3 linux/arch/mips64/sgi-ip22/ip22-irq.S - 1.3 linux/arch/mips64/sgi-ip22/ip22-hpc.c - 1.4 linux/arch/mips64/sgi-ip22/ip22-berr.c - 1.3 linux/arch/mips64/mm/umap.c - 1.6 linux/arch/mips64/arc/file.c - 1.3 linux/arch/mips64/arc/memory.c - 1.6 linux/arch/mips64/mm/fault.c - 1.8 linux/arch/mips64/mm/extable.c - 1.4 linux/arch/mips64/lib/strlen_user.S - 1.3 linux/arch/mips64/lib/strnlen_user.S - 1.3 linux/arch/mips64/lib/strncpy_user.S - 1.3 linux/arch/mips64/lib/memcpy.S - 1.5 linux/arch/mips64/arc/init.c - 1.3 linux/arch/mips64/mm/andes.c - 1.7 linux/arch/mips64/lib/kbd-no.c - 1.3 linux/arch/mips64/lib/floppy-no.c - 1.3 linux/arch/mips64/lib/ide-std.c - 1.3 linux/arch/mips64/lib/ide-no.c - 1.3 linux/arch/mips64/lib/dump_tlb.c - 1.3 linux/arch/mips64/lib/csum_partial_copy.c - 1.3 linux/arch/mips64/lib/csum_partial.S - 1.3 linux/arch/mips64/kernel/traps.c - 1.6 linux/arch/mips64/kernel/unaligned.c - 1.5 linux/arch/mips64/sgi-ip27/ip27-timer.c - 1.8 linux/arch/mips64/sgi-ip27/ip27-setup.c - 1.6 linux/arch/mips64/sgi-ip27/ip27-pci.c - 1.5 linux/arch/mips64/sgi-ip27/ip27-pci-dma.c - 1.4 linux/arch/mips64/sgi-ip27/ip27-memory.c - 1.8 linux/arch/mips64/arc/time.c - 1.3 linux/arch/mips64/sgi-ip27/ip27-klconfig.c - 1.4 linux/arch/mips64/sgi-ip27/ip27-irq.c - 1.8 linux/arch/mips64/sgi-ip27/ip27-irq-glue.S - 1.3 linux/arch/mips64/arc/tree.c - 1.4 linux/arch/mips64/sgi-ip27/ip27-init.c - 1.8 linux/arch/mips64/sgi-ip27/ip27-berr.c - 1.4 linux/arch/mips64/config.in - 1.15 linux/arch/mips64/sgi-ip27/Makefile - 1.6 linux/arch/mips64/sgi-ip22/time.c - 1.3 linux/arch/mips64/sgi-ip22/system.c - 1.3 linux/arch/mips64/sgi-ip22/ip22-timer.c - 1.6 linux/arch/mips64/defconfig-ip22 - 1.10 linux/arch/mips64/kernel/binfmt_elf32.c - 1.6 linux/arch/mips64/kernel/scall_o32.S - 1.7 linux/arch/mips64/kernel/r4k_tlb_debug.c - 1.3 linux/arch/mips64/sgi-ip22/ip22-setup.c - 1.6 linux/arch/mips/sni/dma.c - 1.3 linux/arch/mips64/Makefile - 1.8 linux/arch/mips64/mm/r4xx0.c - 1.8 linux/arch/mips64/mm/loadmmu.c - 1.5 linux/arch/mips64/lib/kbd-std.c - 1.3 linux/arch/mips64/kernel/syscall.c - 1.8 linux/arch/mips64/kernel/signal32.c - 1.8 linux/arch/mips64/kernel/signal.c - 1.7 linux/arch/mips64/arc/misc.c - 1.3 linux/arch/mips64/arc/salone.c - 1.3 linux/arch/mips64/kernel/setup.c - 1.7 linux/arch/mips64/sgi-ip22/ip22-sc.c - 1.5 linux/arch/mips64/kernel/linux32.c - 1.10 linux/arch/mips64/kernel/scall_64.S - 1.9 linux/arch/mips64/defconfig-ip27 - 1.9 linux/arch/mips64/kernel/r4k_tlb_glue.S - 1.4 linux/arch/mips64/kernel/entry.S - 1.6 linux/arch/mips64/kernel/r4k_switch.S - 1.3 linux/arch/mips64/kernel/mips64_ksyms.c - 1.7 linux/arch/mips64/kernel/proc.c - 1.5 linux/arch/mips64/kernel/ptrace.c - 1.7 linux/arch/mips64/kernel/r4k_cache.S - 1.3 linux/arch/mips64/kernel/r4k_genex.S - 1.3 linux/drivers/net/appletalk/ltpc.c - 1.10 linux/drivers/net/appletalk/ipddp.c - 1.8 linux/drivers/net/appletalk/cops.c - 1.12 linux/drivers/ide/ide-pci.c - 1.16 linux/drivers/ide/ide-dma.c - 1.12 linux/drivers/ide/hd.c - 1.11 linux/drivers/ide/amd7409.c - 1.8 linux/Documentation/DocBook/kernel-api.tmpl - 1.11 linux/drivers/sound/i810_audio.c - 1.15 linux/include/asm-mips64/sn/launch.h - 1.2 linux/arch/mips/defconfig-cobalt - 1.4 linux/arch/mips/defconfig-orion - 1.4 linux/arch/mips/defconfig-rm200 - 1.4 linux/arch/mips64/sgi-ip27/ip27-klnuma.c - 1.3 linux/drivers/media/video/zr36120.c - 1.8 linux/drivers/isdn/eicon/sys.h - 1.3 linux/drivers/isdn/eicon/pc.h - 1.3 linux/drivers/isdn/eicon/kprintf.c - 1.5 linux/drivers/isdn/eicon/idi.c - 1.3 linux/drivers/md/lvm.c - 1.18 linux/include/asm-mips/module.h - 1.2 linux/include/asm-mips64/module.h - 1.2 linux/arch/mips64/sgi-ip27/ip27-console.c - 1.2 linux/drivers/net/gt96100eth.h - 1.2 linux/drivers/net/gt96100eth.c - 1.2 linux/drivers/char/qtronix.c - 1.2 linux/arch/mips/mips-boards/malta/malta_setup.c - 1.2 linux/arch/mips/mips-boards/malta/malta_rtc.c - 1.2 linux/arch/mips/mips-boards/malta/malta_int.c - 1.2 linux/arch/mips/mips-boards/generic/time.c - 1.2 linux/arch/mips/mips-boards/generic/pci.c - 1.2 linux/arch/mips/mips-boards/generic/memory.c - 1.2 linux/arch/mips/mips-boards/generic/gdb_hook.c - 1.2 linux/arch/mips/mips-boards/generic/cmdline.c - 1.2 linux/arch/mips/mips-boards/atlas/atlas_setup.c - 1.2 linux/arch/mips/mips-boards/atlas/atlas_rtc.c - 1.2 linux/arch/mips/mips-boards/atlas/atlas_int.c - 1.2 linux/arch/mips/math-emu/cp1emu.c - 1.3 linux/arch/mips/ite-boards/qed-4n-s01b/pci_fixup.c - 1.2 linux/arch/mips/ite-boards/qed-4n-s01b/init.c - 1.2 linux/arch/mips/ite-boards/qed-4n-s01b/Makefile - 1.2 linux/arch/mips/ite-boards/generic/time.c - 1.2 linux/arch/mips/ite-boards/generic/reset.c - 1.2 linux/arch/mips/ite-boards/generic/puts.c - 1.2 linux/arch/mips/ite-boards/generic/pmon_prom.c - 1.2 linux/arch/mips/ite-boards/generic/lpc.c - 1.2 linux/arch/mips/ite-boards/generic/it8172_setup.c - 1.2 linux/arch/mips/ite-boards/generic/it8172_rtc.c - 1.2 linux/arch/mips/ite-boards/generic/it8172_pci.c - 1.2 linux/arch/mips/ite-boards/generic/it8172_cir.c - 1.2 linux/arch/mips/ite-boards/generic/irq.c - 1.3 linux/arch/mips/ite-boards/generic/dbg_io.c - 1.2 linux/arch/mips/ite-boards/generic/Makefile - 1.2 linux/arch/mips/defconfig-it8172 - 1.2 linux/include/asm-mips/it8172/it8172.h - 1.2 linux/include/asm-mips/it8172/it8172_cir.h - 1.2 linux/arch/mips/defconfig-ddb5476 - 1.2 linux/include/asm-mips/it8172/it8172_dbg.h - 1.2 linux/include/asm-mips/it8172/it8172_int.h - 1.2 linux/include/asm-mips/it8172/it8172_lpc.h - 1.2 linux/arch/mips/ddb5476/setup.c - 1.2 linux/arch/mips/ddb5476/pci.c - 1.2 linux/arch/mips/ddb5476/int-handler.S - 1.2 linux/include/asm-mips/it8172/it8172_pci.h - 1.2 linux/drivers/net/irda/irda-usb.c - 1.5 linux/net/bluetooth/hci_core.c - 1.4 linux/drivers/mtd/nftlcore.c - 1.3 linux/include/asm-mips/time.h - 1.2 linux/include/asm-mips/tx3912.h - 1.2 linux/arch/mips/kernel/i8259.c - 1.2 linux/arch/mips/kernel/old-irq.c - 1.2 linux/arch/mips/kernel/old-time.c - 1.2 linux/arch/mips/kernel/pci-dma.c - 1.2 linux/arch/mips64/math-emu/cp1emu.c - 1.2 linux/arch/mips/mm/r5432.c - 1.2 linux/arch/mips/mm/mips32.c - 1.2 linux/drivers/media/video/zr36067.c - 1.3 linux/drivers/net/au1000_eth.c - 1.2 linux/drivers/net/lp486e.c - 1.3 linux/drivers/net/wan/farsync.c - 1.3 linux/drivers/ide/serverworks.c - 1.2 linux/drivers/video/radeonfb.c - 1.2 linux/drivers/video/radeon.h - 1.2 linux/drivers/scsi/dpt_i2o.c - 1.2 From owner-linux-xfs@oss.sgi.com Sun Sep 9 23:47:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A6lOT06633 for linux-xfs-outgoing; Sun, 9 Sep 2001 23:47:24 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A6lJd06614; Sun, 9 Sep 2001 23:47:19 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8A6lKd06615 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 00:11:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A7BMH07057 for linux-xfs-outgoing; Mon, 10 Sep 2001 00:11:22 -0700 Received: from alpha.bytecomm.com.au (byt130674-1.gw.connect.com.au [202.21.11.108]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A7BFd07032 for ; Mon, 10 Sep 2001 00:11:15 -0700 Received: (qmail 23426 invoked from network); 10 Sep 2001 07:11:02 -0000 Received: from unknown (HELO herbie.local) (192.168.0.11) by 192.168.0.1 with SMTP; 10 Sep 2001 07:11:02 -0000 Received: by herbie.local with Internet Mail Service (5.5.1960.3) id ; Mon, 10 Sep 2001 17:11:02 +1000 Message-ID: From: Adrian Head To: Michael Wahlbrink , Adrian Head Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com Subject: RE: Problems with many processes copying large directories across an XFS volume. Date: Mon, 10 Sep 2001 17:11:01 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks for your reply. Very interesting - I will definitely investigate this further. Just a little more info on the actual computers: I'm running these tests on 3 different machines in 2 different places but the common component are the IBM hard drives. On the 2 machines at work I have 4 x 20G IBM drives in a software raid5 and on the machine at home I have 5 x 40G IBM drives in a software raid5 and 2 x 40G IBM drives in a software raid0. The 4 drive array is in a machine at work where it is airconditioned and it has a 200cm3/sec AC fan installed in the case. The drives are spaced about 5mm apart between the top of one drive and the bottom of the other. The 5 drive raid5 and 2 drive raid0 machine at home at the moment is not in an airconditioned room but the case cover is off and the case has 2 x 200cm3/sec AC fans in it and for good measure I also have a 40cm pedestal fan blowing air through the case. The drives in this machine are spaced about 2cm apart from the top of one drive to the bottom of the other. In both environments I have never noticed hard drives that are hot to touch during any of the tests. Therefore, it may not be the external temperature that I have to worry about but the internal temperature of the drive. I'll try to get a thermometer and measure the average external hard drive temperature some time latter this week. Does anyone have any other ideas on this? Michael, what hard drives are you running in your machine and what spacings and what is the ambient temperature please. You can email this directly if you wish as it is a little OT for this list I think. Thanks again Adrian Head Bytecomm P/L > -----Original Message----- > From: Michael Wahlbrink [SMTP:miw@propack-data.com] > Sent: Monday, 10 September 2001 14:56 > To: adrian.head@bytecomm.com.au > Cc: linux-xfs@oss.sgi.com; owner-linux-xfs@oss.sgi.com > Subject: Re: Problems with many processes copying large > directories across an XFS volume. > > > On 10.09.2001 04:00:30 Adrian Head wrote: > [....see subject...] > Hi Adrian, > I've had a quite similar phenomen last weekend. When copiing with many > cp-processes on my xfs-volume i run into io errors or kernel oops. > The solution was that the two disks of the Raidsystem are getting to > hot when I > run these extensive tests (30cp processes and 15 tar processes on > thesame 60 GB > raid 1 volume). Added another fan and all was fine ;-)........... > > cu > michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 00:46:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A7kvE07652 for linux-xfs-outgoing; Mon, 10 Sep 2001 00:46:57 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A7knd07630 for ; Mon, 10 Sep 2001 00:46:49 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id JAA14374; Mon, 10 Sep 2001 09:46:12 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id JAA20134; Mon, 10 Sep 2001 09:46:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 8A06957306; Mon, 10 Sep 2001 09:45:10 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id B6F7325835; Mon, 10 Sep 2001 09:45:09 +0200 (CEST) Message-ID: <3B9C6F85.94B63D87@ch.sauter-bc.com> Date: Mon, 10 Sep 2001 09:45:09 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com Subject: Re: Problems with many processes copying large directories across an XFS volume. References: <01090823430700.01184@HERCULES> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Adrian Adrian Head schrieb: > > I am in the process of building a couple of file servers for various purposes > and over the last week have been running quite a few tests in an attempt to > determine if I trust the hardware/software combination enough for it to be > put into production. > > One of the tests I was doing was trying to simulate many users copying large > directories across an XFS volume. To do this I was generating many > background jobs copying a 4G directory to another directory on the XFS volume. > eg. > #>cp -r 001 002& > #>cp -r 001 003& > #>cp -r 001 004& > ..... > ..... > #>cp -r 001 019& > #>cp -r 001 020& I did similar tests two months ago. I was having problems as well but ufurtunately I don't remember what is was exactly. First question: You created Softraid5, was the raid synced when you started the tests? > Everything would start fine but less than a minute into the test various > hundreds of errors are displayed like: > cp: cannot stat file `/mnt/raid5/filename`: Input/output error > > Once this has happened the XFS volume disappears. By this I mean that it is > still mounted but all files and directories are no longer visible using ls. > Any other file activity results in an Input/Output error. Once I unmount & > mount the volume again the data is again visible up to the point where the > copy failed. > > In the /var/log/messages log around the same time as the copy test I get > entries like: > Sep 9 05:13:46 ATLAS kernel: 02:86: rw=0, want=156092516, limit=360 > Sep 9 05:13:46 ATLAS kernel: attempt to access beyond end of device This looks interesting. I don't know what this means exactly but it looks to me like you managed to create a filesystem bigger than the raid volume was? I got the very same error when I tried to restore data with xfsrestore from DAT (xfsrestore from DLT was fine). The issue is still open. > > The problem is reproduceable on XFS volumes on a 2 disk (IDE) raid0 (SW raid) > partition and on a 5 disk (IDE) raid5 (SW raid) partition. However, there is > no problem with the copy test using ext2 volumes on the above partitions. > The copy test also passes when run on a non-raid drive. > > I am using Kernel 2.4.9 and the relevant latest XFS patch from the patches > directory on the XFS ftp site. > patch-2.4.9-xfs-2001-08-19 > > The thing that really puzzles me is that the above directory copy test runs > fine when I only have 10 background copy jobs running at a time. As soon as > I have 20 background copy jobs running the problem occurs. The system passes > both bonnie++ and mongo.pl tests/benchmarks. > > So from the results I have at the moment it would seem that XFS is stomping > over the raid code or the raid code is stomping over XFS. Should I cross > post this to the raid list as well? > > P.S. I have just noticed on the mailing list archive a note about fixing a > problem that caused mongo.pl to hang. Although my systems don't hang in > mongo do people think I'm seeing the same problem just a different symptom? > > Another issue that I think is not related is that when using the 2.4.9-xfs > kernel, when the kernel identifies the drives during bootup I get IRQ probe > failed errors. > hda: IC35L040AVER07-0, ATA DISK drive > hda: IRQ probe failed (0xfffffff8) > hdb: IC35L040AVER07-0, ATA DISK drive > hdb: IRQ probe failed (0xfffffff8) > ........the rest as normal > > The errors occur when the kernel is run on an ASUS A7V133 motherboard but not > on a ASUS A7V133C. The errors don't happen with a native 2.4.9 kernel > either. Since the errors occur for the 2 drives on the 1st channel of the > 1st IDE controller (which is not related to the raid arrays mentioned above) > and the system still boots - I have not been worried about it. Should I be > worried? > > At this stage I'm unsure what other info people would like. If anyone wants > logs, config files, more information or more testing please tell me. > > Thanks for your time. > > Adrian Head > Bytecomm P/L I have a test system here with SoftRAID5 on 4 U160 SCSI disks. I'll try to kill it today with cp jobs. -Simon From owner-linux-xfs@oss.sgi.com Mon Sep 10 01:02:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A82dY07986 for linux-xfs-outgoing; Mon, 10 Sep 2001 01:02:39 -0700 Received: from atrey.karlin.mff.cuni.cz (root@atrey.karlin.mff.cuni.cz [195.113.31.123]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A82Xd07966 for ; Mon, 10 Sep 2001 01:02:33 -0700 Received: (from jack@localhost) by atrey.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) id KAA03540; Mon, 10 Sep 2001 10:00:26 +0200 Date: Mon, 10 Sep 2001 10:00:26 +0200 From: Jan Kara To: Nathan Scott Cc: Bret Giddings , linux-xfs@oss.sgi.com, samba-technical@lists.samba.org Subject: Re: [patch] Re: XFS, Quotas and Samba Message-ID: <20010910100026.A2992@atrey.karlin.mff.cuni.cz> References: <7AC902A40BEDD411A3A800D0B7847B660882F5@sernt14.essex.ac.uk> <20010906105952.B345981@wobbly.melbourne.sgi.com> <20010906123515.A380241@wobbly.melbourne.sgi.com> <20010906163441.C24754@atrey.karlin.mff.cuni.cz> <20010909205752.A397355@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <20010909205752.A397355@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Sun, Sep 09, 2001 at 08:57:52PM +1100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, > On Thu, Sep 06, 2001 at 04:34:41PM +0200, Jan Kara wrote: > > Hello, > > > > Actually it depends whether the samba code was compiled with > > proper kernel headers. If so the Q_GETQUOTA is defined to be > > right value and so everything should work fine. Ok, to be more > > precise the utils probably won't compile in that case as struct dqblk > > is no more and mem_dqblk should be used instead... But anyway it shouldn't > > break silently. > > Hmm ... I can't see any case where the new VFS quota code will > work (ie. Jan's patches/AC kernels/Redhat 7.1+) with the smbd > code, even if the kernel headers happened to correspond to the > running kernel. As I understand it, the new code returns a u64 > byte count in one field (curspace) where before there was a u32 > block count (curblocks). Is that correct? If so, smbd is in a > bit of strife here cos it peeks at that field in particular... Yes. The returned structure is different and that was a reason why it was renamed to struct mem_dqblk :). So code which is using old structure doesn't compile... > I took a stab at implementing the fix for this problem and for > XFS quota - the XFS code should be correct, the VFS quota code > (v1/v2 stuff) should be too, but I'm less certain on that - see > attached patch. The approach is basically to attempt the old > Linux quotactl for non-XFS filesystems - if that fails, try > the new version. And for XFS filesystems, always use the XFS > quotactl command, which is always the right thing to do. > > Bret - could you let me know if this helps you? The patch seems to have one small problem: if version == 2 then size is set to D2.dqb_curspace but IMHO it should be something like toqb(D2.dqb_curspace). Honza -- Jan Kara SuSE Labs From owner-linux-xfs@oss.sgi.com Mon Sep 10 01:10:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A8AsA08295 for linux-xfs-outgoing; Mon, 10 Sep 2001 01:10:54 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A8Acd08276; Mon, 10 Sep 2001 01:10:39 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8A8Add08277 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 01:30:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A8Upv08690 for linux-xfs-outgoing; Mon, 10 Sep 2001 01:30:51 -0700 Received: from alpha.bytecomm.com.au (byt130674-1.gw.connect.com.au [202.21.11.108]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A8UVd08667 for ; Mon, 10 Sep 2001 01:30:35 -0700 Received: (qmail 23520 invoked from network); 10 Sep 2001 08:30:10 -0000 Received: from unknown (HELO herbie.local) (192.168.0.11) by 192.168.0.1 with SMTP; 10 Sep 2001 08:30:10 -0000 Received: by herbie.local with Internet Mail Service (5.5.1960.3) id ; Mon, 10 Sep 2001 18:30:04 +1000 Message-ID: From: Adrian Head To: Simon Matter , Adrian Head Cc: linux-xfs@oss.sgi.com Subject: RE: Problems with many processes copying large directories across an XFS volume. Date: Mon, 10 Sep 2001 18:29:55 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks for your reply Simon Yes the softraid was fully synced before I started any test. The XFS patch I used to obtain these errors was patch-2.4.9-xfs-2001-08-19 and the errors were: Sep 9 05:13:46 ATLAS kernel: 02:86: rw=0, want=156092516, limit=360 Sep 9 05:13:46 ATLAS kernel: attempt to access beyond end of device When I used a later version of the XFS patch I had more descriptive errors written to /var/log/messages: Sep 10 10:14:57 ATLAS kernel: I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x9802bdc Sep 10 10:14:57 ATLAS kernel: (xlog_iodone") error 5 buf count 32768 Sep 10 10:14:57 ATLAS kernel: xfs_force_shutdown(md(9,0),0x2) called from line 940 of file xfs_log.c. Return address - 0xd8cb66f8 Sep 10 10:14:57 ATLAS kernel: Log I/O Error Detected. Shutting down filesystem: md(9,0) Sep 10 10:14:57 ATLAS kernel: Please umount the filesystem, and rectify the problem(s) Sep 10 10:14:57 ATLAS kernel: xfs_force_shutdown(md(9,0),0x2) called from line 714 of file xfs_log.c. Return address = 0xd8cb65d3 Sep 10 10:14:57 ATLAS kernel: attempt to access beyond end of device Sep 10 10:14:57 ATLAS kernel: 02:82: rw=0, want=1602235696, limit=4 I did think at the time that it may have been issues with XFS stomping all over raid code or raid code stomping all over XFS. Although I not sure now as the 2.4.10-pre2-xfs-2001-09-02 patch never wrote any errors out at all. (please see my 2nd post for more info) Thanks for taking the time to test this on your own machine. Adrian Head Bytecomm P/L > -----Original Message----- > From: Simon Matter [SMTP:simon.matter@ch.sauter-bc.com] > Sent: Monday, 10 September 2001 17:45 > To: adrian.head@bytecomm.com.au > Cc: linux-xfs@oss.sgi.com > Subject: Re: Problems with many processes copying large > directories across an XFS volume. > > Hi Adrian > > I did similar tests two months ago. I was having problems as well but > ufurtunately I don't remember what is was exactly. > First question: You created Softraid5, was the raid synced when you > started the tests? > > > In the /var/log/messages log around the same time as the copy test I > get > > entries like: > > Sep 9 05:13:46 ATLAS kernel: 02:86: rw=0, want=156092516, limit=360 > > Sep 9 05:13:46 ATLAS kernel: attempt to access beyond end of device > > This looks interesting. I don't know what this means exactly but it > looks to me like you managed to create a filesystem bigger than the > raid > volume was? I got the very same error when I tried to restore data > with > xfsrestore from DAT (xfsrestore from DLT was fine). The issue is still > open. > > I have a test system here with SoftRAID5 on 4 U160 SCSI disks. I'll > try > to kill it today with cp jobs. > > -Simon > From owner-linux-xfs@oss.sgi.com Mon Sep 10 01:59:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A8xDl09276 for linux-xfs-outgoing; Mon, 10 Sep 2001 01:59:13 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A8x2d09232 for ; Mon, 10 Sep 2001 01:59:02 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id KAA29419; Mon, 10 Sep 2001 10:58:26 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id KAA26232; Mon, 10 Sep 2001 10:58:14 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 9D5D957306; Mon, 10 Sep 2001 10:57:12 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 4B50E25835; Mon, 10 Sep 2001 10:57:12 +0200 (CEST) Message-ID: <3B9C8068.AF14F8E6@ch.sauter-bc.com> Date: Mon, 10 Sep 2001 10:57:12 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Bret Hughes Cc: linux-xfs Subject: Re: directory cache problems (I think) References: <3B9C4632.2408E16@elevating.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Bret Bret Hughes schrieb: > > I have a configuration on 6 boxes, Duron 700 with 128 MB ram and 10GB > ide harddrives. These machines are all XFS 1.0.1 using the kernel from > the 1.0.1 RH install iso and most of the RH updates. > > They were all placed into service the same day and yesterday 5 days > after they were turned on they all stopped responding to ssh. A couple > would still respond to a ping but nothing else. Actually I caough one > before it quit altogether and rebooted it last night. These machines a > kiosk type display that scroll html and flash pages using (netscape as > the browser). There is no user interaction infact not any input device > at all. A different page is displayed every 10 seconds. > > Now, After rebooting them I can get to the sadc data and looking through > the logs shows really bad stuff happening at 1:00PM yesterday on the one > machine I have really looked at closely. interrupt 14s out the wazoo > and what I think must be the cause, the dentunusd goes to 0. Looking > over the logs of the last few days I can see the dentunusd creeping down > from the beginning at boot of over 20K to 0. > > Since netscape is such a pig I kill it and restart it once an hour and > restart X once a day. both these events seem to take a tremendous toll > on this value and never gain it all back. > > I don't know if this is an XFS issue or not but I thought that I would > start here. Any ideas? I can send all the log data anyone might use if > it would help. Right now I am going to reboot the damn things nightly > like they were windows machines for Christ's sake. > > BTW the same scenario and control scripts run for months on end on RH > 6.2 using the 2.2.3-16 kernel. > > Any tips and or other places to ask are appreciated. > > TIA > > Bret Did you run the RH-6.2 stuff on exactly the same hardware (including same disks?) What about the disks, are they running with DMA enabled? Over here our mailservers used to be IBM PC's with Fujitsu Harddrives. After some time of operation they started to slow down and load started to increase. They even did not respond to ssh sometimes. In the end I saw that those disks failed under the heavy load of the mailserver and I replaced them with other disks. We have hundreds of the same disks in windows desktop PC's with no problem. Linux just pushes the hardware more. Simon From owner-linux-xfs@oss.sgi.com Mon Sep 10 01:59:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A8x8Y09244 for linux-xfs-outgoing; Mon, 10 Sep 2001 01:59:08 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A8wwd09209 for ; Mon, 10 Sep 2001 01:58:59 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id KAA29420; Mon, 10 Sep 2001 10:58:26 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id KAA26246; Mon, 10 Sep 2001 10:58:19 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 3A1B157306; Mon, 10 Sep 2001 10:57:34 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 3527925835; Mon, 10 Sep 2001 10:57:34 +0200 (CEST) Message-ID: <3B9C807E.2D7488E5@ch.sauter-bc.com> Date: Mon, 10 Sep 2001 10:57:34 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Adrian Head Cc: linux-xfs@oss.sgi.com Subject: Re: Problems with many processes copying large directories acrossan XFS volume. References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Adrian Head schrieb: > > Thanks for your reply Simon > > Yes the softraid was fully synced before I started any test. When I started playing around with XFS I used Raid5 and did stress tests while the disks were syncing. The syncing failed several times and I was afraid it is not stable not stress the raid while it is syncing. Fortunately it is not true but the sync aborted due to bad disks. So no problem even if raid is not synced. > > The XFS patch I used to obtain these errors was > patch-2.4.9-xfs-2001-08-19 and the errors were: > Sep 9 05:13:46 ATLAS kernel: 02:86: rw=0, want=156092516, limit=360 > Sep 9 05:13:46 ATLAS kernel: attempt to access beyond end of device > > When I used a later version of the XFS patch I had more descriptive > errors written to /var/log/messages: > Sep 10 10:14:57 ATLAS kernel: I/O error in filesystem ("md(9,0)") > meta-data dev 0x900 block 0x9802bdc > Sep 10 10:14:57 ATLAS kernel: (xlog_iodone") error 5 buf count 32768 > Sep 10 10:14:57 ATLAS kernel: xfs_force_shutdown(md(9,0),0x2) called > from line 940 of file xfs_log.c. Return address - 0xd8cb66f8 > Sep 10 10:14:57 ATLAS kernel: Log I/O Error Detected. Shutting down > filesystem: md(9,0) > Sep 10 10:14:57 ATLAS kernel: Please umount the filesystem, and rectify > the problem(s) > Sep 10 10:14:57 ATLAS kernel: xfs_force_shutdown(md(9,0),0x2) called > from line 714 of file xfs_log.c. Return address = 0xd8cb65d3 > Sep 10 10:14:57 ATLAS kernel: attempt to access beyond end of device > Sep 10 10:14:57 ATLAS kernel: 02:82: rw=0, want=1602235696, limit=4 > > I did think at the time that it may have been issues with XFS stomping > all over raid code or raid code stomping all over XFS. Although I not > sure now as the 2.4.10-pre2-xfs-2001-09-02 patch never wrote any errors > out at all. (please see my 2nd post for more info) I don't use anything special here and no cutting edge stuff. Just the good old 2.4.3-XFS from the RH-7.1-XFS installer. > > Thanks for taking the time to test this on your own machine. The test with 20 simultaneous has just finished successfully. I'm now trying with 40 cp processes. Due to limited disk space I copy only 470M per process. -Simon > > Adrian Head > Bytecomm P/L > > > -----Original Message----- > > From: Simon Matter [SMTP:simon.matter@ch.sauter-bc.com] > > Sent: Monday, 10 September 2001 17:45 > > To: adrian.head@bytecomm.com.au > > Cc: linux-xfs@oss.sgi.com > > Subject: Re: Problems with many processes copying large > > directories across an XFS volume. > > > > Hi Adrian > > > > I did similar tests two months ago. I was having problems as well but > > ufurtunately I don't remember what is was exactly. > > First question: You created Softraid5, was the raid synced when you > > started the tests? > > > > > In the /var/log/messages log around the same time as the copy test I > > get > > > entries like: > > > Sep 9 05:13:46 ATLAS kernel: 02:86: rw=0, want=156092516, limit=360 > > > Sep 9 05:13:46 ATLAS kernel: attempt to access beyond end of device > > > > This looks interesting. I don't know what this means exactly but it > > looks to me like you managed to create a filesystem bigger than the > > raid > > volume was? I got the very same error when I tried to restore data > > with > > xfsrestore from DAT (xfsrestore from DLT was fine). The issue is still > > open. > > > > I have a test system here with SoftRAID5 on 4 U160 SCSI disks. I'll > > try > > to kill it today with cp jobs. > > > > -Simon > > From owner-linux-xfs@oss.sgi.com Mon Sep 10 02:05:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A95G109644 for linux-xfs-outgoing; Mon, 10 Sep 2001 02:05:16 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A95Dd09623 for ; Mon, 10 Sep 2001 02:05:13 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8A951523078 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Mon, 10 Sep 2001 02:05:01 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id LAA225341 for ; Mon, 10 Sep 2001 11:05:07 +0200 (CEST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA02931; Mon, 10 Sep 2001 20:03:33 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id UAA60160; Mon, 10 Sep 2001 20:03:31 +1100 (AEDT) Date: Mon, 10 Sep 2001 20:03:31 +1100 From: Nathan Scott To: Jan Kara Cc: Bret Giddings , linux-xfs@oss.sgi.com, samba-technical@lists.samba.org Subject: Re: [patch] Re: XFS, Quotas and Samba Message-ID: <20010910200331.B341029@wobbly.melbourne.sgi.com> References: <7AC902A40BEDD411A3A800D0B7847B660882F5@sernt14.essex.ac.uk> <20010906105952.B345981@wobbly.melbourne.sgi.com> <20010906123515.A380241@wobbly.melbourne.sgi.com> <20010906163441.C24754@atrey.karlin.mff.cuni.cz> <20010909205752.A397355@wobbly.melbourne.sgi.com> <20010910100026.A2992@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010910100026.A2992@atrey.karlin.mff.cuni.cz>; from jack@suse.cz on Mon, Sep 10, 2001 at 10:00:26AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Jan, On Mon, Sep 10, 2001 at 10:00:26AM +0200, Jan Kara wrote: > Hello, > ... > The patch seems to have one small problem: if version == 2 then > size is set to D2.dqb_curspace but IMHO it should be something like > toqb(D2.dqb_curspace). > There's a line in there before "curspace" is used which converts from bytes to 1K blocks ("curspace >>= 10;"), and we set blocksize to 1K for both VFS quota versions ... is that approach too simple? (do I need to do the FIOQSIZE thing or something more complex like that?) thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Sep 10 02:34:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8A9YJE10341 for linux-xfs-outgoing; Mon, 10 Sep 2001 02:34:19 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8A9Xxd10315; Mon, 10 Sep 2001 02:33:59 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8A9Y0d10318 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 04:04:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AB4H912216 for linux-xfs-outgoing; Mon, 10 Sep 2001 04:04:17 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AB3vd12193; Mon, 10 Sep 2001 04:03:57 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8AB3wd12194 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 05:02:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AC2cX13280 for linux-xfs-outgoing; Mon, 10 Sep 2001 05:02:38 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AC2Zd13261 for ; Mon, 10 Sep 2001 05:02:35 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id OAA06593 for ; Mon, 10 Sep 2001 14:02:18 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id OAA10818 for linux-xfs@oss.sgi.com; Mon, 10 Sep 2001 14:02:07 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id C15A057306 for ; Mon, 10 Sep 2001 14:01:33 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id B7C8D25835 for ; Mon, 10 Sep 2001 14:01:33 +0200 (CEST) Message-ID: <3B9CAB9D.28502B00@ch.sauter-bc.com> Date: Mon, 10 Sep 2001 14:01:33 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: linux-xfs Subject: Updated quota RPM for RedHat 7.1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've just checked for updates for RH-7.1 and found a new quota RPM. I guess it wouldn't be a good idea to install this one since the quota package for XFS is modified. Did I assume right? Simon From owner-linux-xfs@oss.sgi.com Mon Sep 10 05:27:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8ACRNg13804 for linux-xfs-outgoing; Mon, 10 Sep 2001 05:27:23 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8ACRId13782; Mon, 10 Sep 2001 05:27:18 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8ACRJd13783 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 05:45:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8ACjxn14258 for linux-xfs-outgoing; Mon, 10 Sep 2001 05:45:59 -0700 Received: from atlas.cc.itu.edu.tr (atlas.cc.itu.edu.tr [160.75.2.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8ACjrd14237 for ; Mon, 10 Sep 2001 05:45:54 -0700 Received: from aontws4044 (AONTWS4044.cc.itu.edu.tr [160.75.5.44]) by atlas.cc.itu.edu.tr (8.9.3/8.9.3) with SMTP id PAA05720 for ; Mon, 10 Sep 2001 15:45:46 +0300 From: "Seref Tufan Sen" To: Subject: RE: Problems with many processes copying large directories across an XFS volume.[Offtpic] Date: Mon, 10 Sep 2001 15:51:52 +0300 Message-ID: <001201c139f7$5d5b62a0$2c054ba0@aontws4044> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I got 7 copies of this message. Am I the only one with this problem ??? -----Original Message----- From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com]On Behalf Of Michael Wahlbrink Sent: Monday, September 10, 2001 7:56 AM To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com; owner-linux-xfs@oss.sgi.com Subject: Re: Problems with many processes copying large directories across an XFS volume. On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 05:47:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AClE814397 for linux-xfs-outgoing; Mon, 10 Sep 2001 05:47:14 -0700 Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8ACl8d14377 for ; Mon, 10 Sep 2001 05:47:09 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id f8ACl2a15101 for ; Mon, 10 Sep 2001 21:47:02 +0900 (JST) Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id f8ACl2c13613 for ; Mon, 10 Sep 2001 21:47:02 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv.nec.co.jp (8.11.6/3.7W-MAILSV-NEC) with ESMTP id f8ACl1l07835 for ; Mon, 10 Sep 2001 21:47:01 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA401 for ; Mon, 10 Sep 2001 21:46:58 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Mon Sep 10 21:46:57 2001 +0900 Received: from rifu.bsd.tnes.nec.co.jp (IDENT:root@rifu.bsd.tnes.nec.co.jp [10.1.101.142]) by mailsv.tnes.nec.co.jp (8.9.3/3.7W01031510) with ESMTP id VAA80635; Mon, 10 Sep 2001 21:46:58 +0900 (JST) Received: from tagajo.bsd.tnes.nec.co.jp (tagajo.bsd.tnes.nec.co.jp [10.1.101.146]) by rifu.bsd.tnes.nec.co.jp (8.10.2+3.3W/3.7W/BSD-TNES-MX01) with ESMTP id f8ACkwL10115; Mon, 10 Sep 2001 21:46:58 +0900 Received: (from sasaki@localhost) by tagajo.bsd.tnes.nec.co.jp (8.8.5+2.7Wbeta5/3.5Wpl1-97090809) id VAA27978; Mon, 10 Sep 2001 21:46:58 +0900 (JST) Message-Id: <200109101246.VAA27978@tagajo.bsd.tnes.nec.co.jp> To: Timothy Shimmin cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump/xfsrestore failed sometimes when running QA suite 022 In-reply-to: Your message of Mon, 10 Sep 2001 14:16:41 +1100. <20010910141641.L96131@boing.melbourne.sgi.com> Date: Mon, 10 Sep 2001 21:46:58 +0900 From: Takayuki Sasaki Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thank you for your fast response. Timothy Shimmin wrote, > Do you have top of tree cmds and kernel ? In this morning, I could not do a CVSup too as someone reported, so, I tried QA suite 022 three times using the CVS kernel and cmds which were updated on last friday. Then, all of them have been passed :-) I'll try more tonight. > cmd/xfstests/022 has failed reliably for us in recent times, > but over the last few days (Nathan looks after our QA he'll > know exactly when), it has been passing reliably. > I have been meaning to look into 022 and 024 but only > looked at 024 recently. > I do not know exactly what has changed to cause 022 > to pass now. > > xfsdump uses an xfs feature called bulkstat'ing to speed up > the stat'ing of all the inodes of the file system. > However, it apparently snapshots the info from the disk blocks > instead of going through the in-core data structures. > This means that if this data is not flushed to disk completely > when xfsdump is running then it won't have the latest stat > information. Hmmm... I see. > So for the QA testing, after populating an FS I would call > _stable_fs to do sync and sleep. However, I didn't do this > in every case such as the case where I append to files to > test out incremental dumps in 024. > So I added the call to _stable_fs in common.dump for this. > I also changed from sync/sleep to umount/mount to be sure > that the changes are flushed to disk before proceeding. > So this may have also affected 022. > However, by putting back the old behaviour I was still unable > to get 022 to fail. I would like to know that whether it is correct way or workaround to dump the XFS file system which requires preceding unmount and mount, not only for QA suite but also on a production environment. Could you explain me about this? Best Regards, Takayuki From owner-linux-xfs@oss.sgi.com Mon Sep 10 05:56:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8ACuIp14740 for linux-xfs-outgoing; Mon, 10 Sep 2001 05:56:18 -0700 Received: from linux.compucomis.net (linux.CompuComIS.net [216.140.122.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8ACsud14684 for ; Mon, 10 Sep 2001 05:55:35 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id 46662139E5; Mon, 10 Sep 2001 08:50:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id 5E5B3139E4; Mon, 10 Sep 2001 08:50:19 -0400 (EDT) Date: Mon, 10 Sep 2001 08:50:18 -0400 (EDT) From: Mike Burger To: Simon Matter Cc: linux-xfs Subject: Re: Updated quota RPM for RedHat 7.1 In-Reply-To: <3B9CAB9D.28502B00@ch.sauter-bc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hmm...that probably explains why I can't seem to enable quotas. What is the version of the quota package that comes with the XFS install? On Mon, 10 Sep 2001, Simon Matter wrote: > I've just checked for updates for RH-7.1 and found a new quota RPM. I > guess it wouldn't be a good idea to install this one since the quota > package for XFS is modified. Did I assume right? > > Simon > > > From owner-linux-xfs@oss.sgi.com Mon Sep 10 05:57:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8ACv5U14824 for linux-xfs-outgoing; Mon, 10 Sep 2001 05:57:05 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8ACuvd14804 for ; Mon, 10 Sep 2001 05:56:57 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id OAA21312; Mon, 10 Sep 2001 14:56:35 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id OAA15236; Mon, 10 Sep 2001 14:56:09 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id A8FAB57306; Mon, 10 Sep 2001 14:55:24 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 6192125835; Mon, 10 Sep 2001 14:55:24 +0200 (CEST) Message-ID: <3B9CB83C.38153FEE@ch.sauter-bc.com> Date: Mon, 10 Sep 2001 14:55:24 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Mike Burger Cc: linux-xfs Subject: Re: Updated quota RPM for RedHat 7.1 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mike Burger schrieb: > > Hmm...that probably explains why I can't seem to enable quotas. > > What is the version of the quota package that comes with the XFS install? The RH-7.1XFS 1.0.1 comes with quota-3.01-pre7 Simon > > On Mon, 10 Sep 2001, Simon Matter wrote: > > > I've just checked for updates for RH-7.1 and found a new quota RPM. I > > guess it wouldn't be a good idea to install this one since the quota > > package for XFS is modified. Did I assume right? > > > > Simon > > > > > > From owner-linux-xfs@oss.sgi.com Mon Sep 10 06:06:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AD6pp15270 for linux-xfs-outgoing; Mon, 10 Sep 2001 06:06:51 -0700 Received: from minerva.local.lan (madkiss@pD952C80F.dip.t-dialin.net [217.82.200.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AD6ld15249 for ; Mon, 10 Sep 2001 06:06:47 -0700 Received: from minerva.local.lan (madkiss@localhost [127.0.0.1]) by localhost (8.12.0.Beta19/8.12.0.Beta16/Debian 8.12.0.Beta16) with ESMTP id f8AD6K2S002166 for ; Mon, 10 Sep 2001 15:06:21 +0200 Received: (from madkiss@localhost) by minerva.local.lan (8.12.0.Beta19/8.12.0.Beta16/Debian 8.12.0.Beta16) id f8AD6KVm002165 for linux-xfs@oss.sgi.com; Mon, 10 Sep 2001 15:06:20 +0200 From: Martin Loschwitz Date: Mon, 10 Sep 2001 15:06:20 +0200 To: linux-xfs@oss.sgi.com Subject: xfs-cvstree-errors Message-ID: <20010910150620.A2155@Minerva> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.20i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello ppl, i downloaded your xfs-cvs-tree for Linux-kernel 2.4. I tried to compile it, but when i do "make dep", it finishs with: udp.c utils.c > .depend make[4]: Leaving directory `/usr/src/linux-2.4-xfs/linux/net/ipv4' make -C ipv4/netfilter fastdep make[4]: Entering directory `/usr/src/linux-2.4-xfs/linux/net/ipv4/netfilter' .depend:12: *** missing separator. Stop. make[4]: Leaving directory `/usr/src/linux-2.4-xfs/linux/net/ipv4/netfilter' make[3]: *** [_sfdep_ipv4/netfilter] Error 2 make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/net' make[2]: *** [fastdep] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/net' make[1]: *** [_sfdep_net] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux' make: *** [dep-files] Error 2 is that a bug, and if it's, how to patch? -- greetings, Madkiss "Who cares if it doesn't do anything? It was made with our new Triple-Iso-Bifurcated-Krypton-Gate-MOS process ..." From owner-linux-xfs@oss.sgi.com Mon Sep 10 06:14:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8ADE9U15503 for linux-xfs-outgoing; Mon, 10 Sep 2001 06:14:09 -0700 Received: from acmex.gatech.edu (IDENT:root@acmex.gatech.edu [130.207.165.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8ADDed15482 for ; Mon, 10 Sep 2001 06:13:40 -0700 Received: from [130.207.197.237] ([130.207.197.237]) by acmex.gatech.edu (8.9.2/8.9.2) with ESMTP id JAA04209 for ; Mon, 10 Sep 2001 09:13:40 -0400 (EDT) Subject: 2.4.9 oops - dual athlon/2gb ram From: Rob Myers To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.13.99+cvs.2001.09.08.07.08 (Preview Release) Date: 10 Sep 2001 09:16:35 -0400 Message-Id: <1000127795.10581.13.camel@ransom> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hello i generated an oops after running ctcs (http://sourceforge.net/projects/va-ctcs/) for 5 days. This machine is a dual athlon with 2gb ram and a single scsi disk. Linux version 2.4.9-xfs (root@monsoon) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)) #6 SMP Fri Aug 24 00:31:54 EDT 2001 would switching back to kgcc solve this problem? thanks rob. ksymoops 2.4.0 on i686 2.4.9-xfs. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.9-xfs/ (default) -m /boot/System.map-2.4.9-xfs (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Error (regular_file): read_ksyms stat /proc/ksyms failed No modules in ksyms, skipping objects No ksyms, skipping lsmod Sep 10 03:36:30 monsoon kernel: Oops: 0000 Sep 10 03:36:30 monsoon kernel: CPU: 1 Sep 10 03:36:30 monsoon kernel: EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Sep 10 03:36:30 monsoon kernel: EFLAGS: 00010246 Sep 10 03:36:30 monsoon kernel: eax: 00000000 ebx: 00000000 ecx: 00000070 edx: 00000000 Sep 10 03:36:30 monsoon kernel: esi: 00000000 edi: e0eb6ed8 ebp: f7bd7938 esp: f7bd78f4 Sep 10 03:36:30 monsoon kernel: ds: 0018 es: 0018 ss: 0018 Sep 10 03:36:30 monsoon kernel: Process bdflush (pid: 7, stackpage=f7bd7000) Sep 10 03:36:30 monsoon kernel: Stack: e0eb6ed8 00000000 00000000 c01a22ee e0eb6f64 00000001 f7b47800 00000000 Sep 10 03:36:30 monsoon kernel: 00000000 00000001 00000001 00000001 f7711000 00000000 f7bd7958 0001c87d Sep 10 03:36:30 monsoon kernel: 00000009 f7bd7968 c0188935 e0eb6ed8 00000000 f7bd7958 f7bd7958 00000000 Sep 10 03:36:30 monsoon kernel: Call Trace: [] [] [] <4>eth0: card reports no resources. Sep 10 03:36:30 monsoon kernel: [] [] Sep 10 03:36:30 monsoon kernel: [] [] [] [] [] [] Sep 10 03:36:30 monsoon kernel: [] [] [] [] [] [] Sep 10 03:36:30 monsoon kernel: [] [] [] [] [] [] Sep 10 03:36:30 monsoon kernel: [] [] [] [] Sep 10 03:36:30 monsoon kernel: Code: 8b 70 30 50 53 56 57 e8 79 63 01 00 83 c4 1c 85 c0 74 08 e9 >>EIP; c018bf2b <===== Trace; c01a22ee Trace; c0188935 Trace; c01890fe Trace; c0188ba6 Trace; c018acd5 Trace; c0197b96 Trace; c0194254 Trace; c01a1117 Trace; c01a1117 Trace; c019af57 Trace; c0183558 Trace; c01dfa5b Trace; c012bef9 Trace; c01dde4a Trace; c0185f43 <__pb_block_prepare_write_async+d3/270> Trace; c02068b9 Trace; c0185af1 Trace; c01dde00 Trace; c01ddff1 Trace; c01dde00 Trace; c0134691 <_write_buffer+71/d0> Trace; c01348b1 Trace; c0111d80 Trace; c01381f4 Trace; c0105000 <_stext+0/0> Trace; c01055e6 Trace; c0138160 Code; c018bf2b 00000000 <_EIP>: Code; c018bf2b <===== 0: 8b 70 30 mov 0x30(%eax),%esi <===== Code; c018bf2e 3: 50 push %eax Code; c018bf2f 4: 53 push %ebx Code; c018bf30 5: 56 push %esi Code; c018bf31 6: 57 push %edi Code; c018bf32 7: e8 79 63 01 00 call 16385 <_EIP+0x16385> c01a22b0 Code; c018bf37 c: 83 c4 1c add $0x1c,%esp Code; c018bf3a f: 85 c0 test %eax,%eax Code; c018bf3c 11: 74 08 je 1b <_EIP+0x1b> c018bf46 Code; c018bf3e 13: e9 00 00 00 00 jmp 18 <_EIP+0x18> c018bf43 1 warning and 1 error issued. Results may not be reliable. GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (no debugging symbols found)... (gdb) disass xfs_alloc_lookup Dump of assembler code for function xfs_alloc_lookup: 0xc018be30 : push %ebp 0xc018be31 : mov %esp,%ebp 0xc018be33 : push %edi 0xc018be34 : push %esi 0xc018be35 : xor %esi,%esi 0xc018be37 : push %ebx 0xc018be38 : sub $0x2c,%esp 0xc018be3b : mov 0x8(%ebp),%eax 0xc018be3e : incl 0xc03cd930 0xc018be44 : mov 0x8(%ebp),%edx 0xc018be47 : movl $0x0,0xffffffdc(%ebp) 0xc018be4e : mov 0x8(%ebp),%ecx 0xc018be51 : mov 0x4(%eax),%eax 0xc018be54 : mov %eax,0xffffffd4(%ebp) 0xc018be57 : mov 0x74(%edx),%eax 0xc018be5a : mov 0x30(%eax),%edx 0xc018be5d : mov 0x8(%edx),%eax 0xc018be60 : bswap %eax 0xc018be62 : mov %eax,0xffffffd0(%ebp) 0xc018be65 : mov %eax,0xffffffe4(%ebp) 0xc018be68 : mov 0x70(%ecx),%eax 0xc018be6b : mov 0x10(%edx,%eax,4),%eax 0xc018be6f : bswap %eax 0xc018be71 : mov %eax,0xffffffe8(%ebp) 0xc018be74 : movzbl 0x6c(%ecx),%eax 0xc018be78 : movl $0x1,0xffffffe0(%ebp) 0xc018be7f : dec %eax 0xc018be80 : mov %eax,0xffffffd8(%ebp) 0xc018be83 : js 0xc018c060 0xc018be89 : lea 0x0(%esi,1),%esi 0xc018be90 : mov 0xffffffd4(%ebp),%ecx 0xc018be93 : mov 0xffffffe4(%ebp),%eax 0xc018be96 : mul 0x78(%ecx),%eax 0xc018be99 : movzbl 0x18e(%ecx),%ecx 0xc018bea0 : mov %eax,%ebx 0xc018bea2 : mov 0xffffffe8(%ebp),%eax 0xc018bea5 : mov %edx,%esi 0xc018bea7 : xor %edx,%edx 0xc018bea9 : add %eax,%ebx 0xc018beab : adc %edx,%esi 0xc018bead : xor %edi,%edi 0xc018beaf : mov 0xffffffd8(%ebp),%edx 0xc018beb2 : shld %cl,%ebx,%esi 0xc018beb5 : shl %cl,%ebx 0xc018beb7 : test $0x20,%cl 0xc018beba : mov 0x8(%ebp),%ecx 0xc018bebd : cmovne %ebx,%esi 0xc018bec0 : cmovne %edi,%ebx 0xc018bec3 : mov 0x24(%ecx,%edx,4),%eax 0xc018bec7 : mov %eax,%edi 0xc018bec9 : mov %eax,0xfffffff0(%ebp) 0xc018becc : test %edi,%edi 0xc018bece : je 0xc018bee9 0xc018bed0 : mov 0x18(%edi),%edx 0xc018bed3 : mov 0x14(%edi),%eax 0xc018bed6 : mov %edx,%ecx 0xc018bed8 : xor %esi,%ecx 0xc018beda : xor %ebx,%eax 0xc018bedc : or %eax,%ecx 0xc018bede : je 0xc018bee9 0xc018bee0 : movl $0x0,0xfffffff0(%ebp) 0xc018bee7 : xor %edi,%edi 0xc018bee9 : test %edi,%edi 0xc018beeb : jne 0xc018bf43 0xc018beed : push $0x2 0xc018beef : lea 0xfffffff0(%ebp),%eax 0xc018bef2 : mov 0xffffffe8(%ebp),%esi 0xc018bef5 : push %eax 0xc018bef6 : mov 0xffffffd0(%ebp),%ebx 0xc018bef9 : mov 0x8(%ebp),%edi 0xc018befc : push $0x0 0xc018befe : mov 0xffffffd4(%ebp),%edx 0xc018bf01 : push %esi 0xc018bf02 : push %ebx 0xc018bf03 : mov (%edi),%ecx 0xc018bf05 : push %ecx 0xc018bf06 : push %edx 0xc018bf07 : call 0xc01a2a50 0xc018bf0c : add $0x1c,%esp 0xc018bf0f : test %eax,%eax 0xc018bf11 : jne 0xc018c14c 0xc018bf17 : mov 0xfffffff0(%ebp),%eax 0xc018bf1a : mov 0xffffffd8(%ebp),%esi 0xc018bf1d : push %eax 0xc018bf1e : push %esi 0xc018bf1f : push %edi 0xc018bf20 : call 0xc01a2d90 0xc018bf25 : mov 0xfffffff0(%ebp),%eax 0xc018bf28 : mov 0xffffffd8(%ebp),%ebx 0xc018bf2b : mov 0x30(%eax),%esi 0xc018bf2e : push %eax 0xc018bf2f : push %ebx 0xc018bf30 : push %esi 0xc018bf31 : push %edi 0xc018bf32 : call 0xc01a22b0 0xc018bf37 : add $0x1c,%esp 0xc018bf3a : test %eax,%eax 0xc018bf3c : je 0xc018bf46 0xc018bf3e : jmp 0xc018c14c 0xc018bf43 : mov 0x30(%edi),%esi 0xc018bf46 : mov 0xffffffe0(%ebp),%ecx 0xc018bf49 : test %ecx,%ecx 0xc018bf4b : jne 0xc018bf60 0xc018bf4d : movl $0x1,0xffffffdc(%ebp) 0xc018bf54 : jmp 0xc018c010 0xc018bf59 : lea 0x0(%esi,1),%esi 0xc018bf60 : movl $0x0,0xffffffcc(%ebp) 0xc018bf67 : mov 0xffffffd8(%ebp),%edx 0xc018bf6a : movl $0x0,0xffffffc8(%ebp) 0xc018bf71 : test %edx,%edx 0xc018bf73 : jle 0xc018bf80 0xc018bf75 : lea 0x10(%esi),%eax 0xc018bf78 : mov %eax,0xffffffcc(%ebp) 0xc018bf7b : jmp 0xc018bf86 0xc018bf7d : lea 0x0(%esi),%esi 0xc018bf80 : lea 0x10(%esi),%edx 0xc018bf83 : mov %edx,0xffffffc8(%ebp) 0xc018bf86 : movzwl 0x6(%esi),%eax 0xc018bf8a : mov $0x1,%ebx 0xc018bf8f : xchg %al,%ah 0xc018bf91 : movzwl %ax,%ecx 0xc018bf94 : test %ecx,%ecx 0xc018bf96 : je 0xc018c110 0xc018bf9c : cmp %ecx,%ebx 0xc018bf9e : jg 0xc018c010 0xc018bfa0 : incl 0xc03cd934 0xc018bfa6 : lea (%ecx,%ebx,1),%edi 0xc018bfa9 : mov 0xffffffd8(%ebp),%eax 0xc018bfac : sar %edi 0xc018bfae : mov %edi,0xffffffdc(%ebp) 0xc018bfb1 : test %eax,%eax 0xc018bfb3 : jle 0xc018bfc0 0xc018bfb5 : mov 0xffffffcc(%ebp),%edx 0xc018bfb8 : jmp 0xc018bfc6 0xc018bfba : lea 0x0(%esi),%esi 0xc018bfc0 : mov 0xffffffc8(%ebp),%edx 0xc018bfc3 : mov 0xffffffdc(%ebp),%edi 0xc018bfc6 : lea (%edx,%edi,8),%eax 0xc018bfc9 : mov 0xfffffff8(%eax),%edx 0xc018bfcc : bswap %edx 0xc018bfce : mov 0xfffffffc(%eax),%eax 0xc018bfd1 : bswap %eax 0xc018bfd3 : mov 0x8(%ebp),%edi 0xc018bfd6 : cmpl $0x0,0x70(%edi) 0xc018bfda : je 0xc018bfe7 0xc018bfdc : mov 0x8(%ebp),%edi 0xc018bfdf : sub 0xc(%edi),%eax 0xc018bfe2 : mov %eax,0xffffffe0(%ebp) 0xc018bfe5 : jne 0xc018bfef 0xc018bfe7 : mov 0x8(%edi),%eax 0xc018bfea : sub %eax,%edx 0xc018bfec : mov %edx,0xffffffe0(%ebp) 0xc018bfef : mov 0xffffffe0(%ebp),%eax 0xc018bff2 : test %eax,%eax 0xc018bff4 : jns 0xc018c000 0xc018bff6 : mov 0xffffffdc(%ebp),%ebx 0xc018bff9 : inc %ebx 0xc018bffa : jmp 0xc018bf9c 0xc018bffc : lea 0x0(%esi,1),%esi 0xc018c000 : mov 0xffffffe0(%ebp),%edi 0xc018c003 : test %edi,%edi 0xc018c005 : jle 0xc018c010 0xc018c007 : mov 0xffffffdc(%ebp),%ecx 0xc018c00a : dec %ecx 0xc018c00b : jmp 0xc018bf9c 0xc018c00d : lea 0x0(%esi),%esi 0xc018c010 : mov 0xffffffd8(%ebp),%ebx 0xc018c013 : test %ebx,%ebx 0xc018c015 : jle 0xc018c057 0xc018c017 : mov 0xffffffe0(%ebp),%ecx 0xc018c01a : test %ecx,%ecx 0xc018c01c : jle 0xc018c032 0xc018c01e : decl 0xffffffdc(%ebp) 0xc018c021 : mov $0x1,%eax 0xc018c026 : mov 0xffffffdc(%ebp),%edx 0xc018c029 : test %edx,%edx 0xc018c02b : cmovg 0xffffffdc(%ebp),%eax 0xc018c02f : mov %eax,0xffffffdc(%ebp) 0xc018c032 : mov 0x8(%ebp),%edx 0xc018c035 : mov 0xffffffdc(%ebp),%ecx 0xc018c038 : mov 0xffffffd8(%ebp),%edi 0xc018c03b : mov 0x4(%edx),%eax 0xc018c03e : mov 0x1a4(%eax),%eax 0xc018c044 : shl $0x3,%eax 0xc018c047 : lea (%eax,%ecx,4),%eax 0xc018c04a : mov 0xc(%eax,%esi,1),%eax 0xc018c04e : bswap %eax 0xc018c050 : mov %eax,0xffffffe8(%ebp) 0xc018c053 : mov %ecx,0x44(%edx,%edi,4) 0xc018c057 : decl 0xffffffd8(%ebp) 0xc018c05a : jns 0xc018be90 0xc018c060 : cmpl $0x1,0xc(%ebp) 0xc018c064 : je 0xc018c0d0 0xc018c066 : mov 0xffffffe0(%ebp),%edi 0xc018c069 : test %edi,%edi 0xc018c06b : jns 0xc018c0d0 0xc018c06d : incl 0xffffffdc(%ebp) 0xc018c070 : cmpl $0x2,0xc(%ebp) 0xc018c074 : jne 0xc018c0e5 0xc018c076 : movzwl 0x6(%esi),%eax 0xc018c07a : xchg %al,%ah 0xc018c07c : movzwl %ax,%eax 0xc018c07f : cmp %eax,0xffffffdc(%ebp) 0xc018c082 : jle 0xc018c0e5 0xc018c084 : mov 0xc(%esi),%eax 0xc018c087 : bswap %eax 0xc018c089 : inc %eax 0xc018c08a : je 0xc018c0e5 0xc018c08c : mov 0xffffffdc(%ebp),%eax 0xc018c08f : mov 0x8(%ebp),%edx 0xc018c092 : mov %eax,0x44(%edx) 0xc018c095 : lea 0xffffffec(%ebp),%eax 0xc018c098 : push %eax 0xc018c099 : push $0x0 0xc018c09b : push %edx 0xc018c09c : call 0xc018d230 0xc018c0a1 : add $0xc,%esp 0xc018c0a4 : test %eax,%eax 0xc018c0a6 : jne 0xc018c14c 0xc018c0ac : cmpl $0x1,0xffffffec(%ebp) 0xc018c0b0 : mov $0x3de,%eax 0xc018c0b5 : jne 0xc018c14c 0xc018c0bb : mov 0x10(%ebp),%ecx 0xc018c0be : xor %eax,%eax 0xc018c0c0 : movl $0x1,(%ecx) 0xc018c0c6 : jmp 0xc018c14c 0xc018c0cb : nop 0xc018c0cc : lea 0x0(%esi,1),%esi 0xc018c0d0 : cmpl $0x1,0xc(%ebp) 0xc018c0d4 : jne 0xc018c0e5 0xc018c0d6 : mov 0xffffffdc(%ebp),%eax 0xc018c0d9 : dec %eax 0xc018c0da : cmpl $0x1,0xffffffe0(%ebp) 0xc018c0de : cmovl 0xffffffdc(%ebp),%eax 0xc018c0e2 : mov %eax,0xffffffdc(%ebp) 0xc018c0e5 : mov 0xffffffdc(%ebp),%edi 0xc018c0e8 : mov 0x8(%ebp),%eax 0xc018c0eb : test %edi,%edi 0xc018c0ed : mov %edi,0x44(%eax) 0xc018c0f0 : je 0xc018c0ff 0xc018c0f2 : movzwl 0x6(%esi),%eax 0xc018c0f6 : xchg %al,%ah 0xc018c0f8 : movzwl %ax,%eax 0xc018c0fb : cmp %eax,%edi 0xc018c0fd : jle 0xc018c130 0xc018c0ff : mov 0x10(%ebp),%edx 0xc018c102 : movl $0x0,(%edx) 0xc018c108 : jmp 0xc018c14a 0xc018c10a : lea 0x0(%esi),%esi 0xc018c110 : xor %eax,%eax 0xc018c112 : mov 0x8(%ebp),%ecx 0xc018c115 : cmpl $0x1,0xc(%ebp) 0xc018c119 : setne %al 0xc018c11c : mov %eax,0x44(%ecx) 0xc018c11f : xor %eax,%eax 0xc018c121 : mov 0x10(%ebp),%edi 0xc018c124 : movl $0x0,(%edi) 0xc018c12a : jmp 0xc018c14c 0xc018c12c : lea 0x0(%esi,1),%esi 0xc018c130 : mov 0xc(%ebp),%ebx 0xc018c133 : xor %eax,%eax 0xc018c135 : test %ebx,%ebx 0xc018c137 : jne 0xc018c140 0xc018c139 : mov 0xffffffe0(%ebp),%ecx 0xc018c13c : test %ecx,%ecx 0xc018c13e : jne 0xc018c145 0xc018c140 : mov $0x1,%eax 0xc018c145 : mov 0x10(%ebp),%edx 0xc018c148 : mov %eax,(%edx) 0xc018c14a : xor %eax,%eax 0xc018c14c : lea 0xfffffff4(%ebp),%esp 0xc018c14f : pop %ebx 0xc018c150 : pop %esi 0xc018c151 : pop %edi 0xc018c152 : pop %ebp 0xc018c153 : ret 0xc018c154 : lea 0x0(%esi),%esi 0xc018c15a : lea 0x0(%edi),%edi End of assembler dump. (gdb) From owner-linux-xfs@oss.sgi.com Mon Sep 10 06:37:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8ADbdE16045 for linux-xfs-outgoing; Mon, 10 Sep 2001 06:37:39 -0700 Received: from linux.compucomis.net (linux.CompuComIS.net [216.140.122.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8ADZad16000 for ; Mon, 10 Sep 2001 06:37:21 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id D2E9E139DA; Mon, 10 Sep 2001 09:35:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id A9E42139D1; Mon, 10 Sep 2001 09:35:07 -0400 (EDT) Date: Mon, 10 Sep 2001 09:35:07 -0400 (EDT) From: Mike Burger To: Simon Matter Cc: linux-xfs Subject: Re: Updated quota RPM for RedHat 7.1 In-Reply-To: <3B9CB83C.38153FEE@ch.sauter-bc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Blarg. I think I might have let up2date update it. Crud...guess I'll have to put the SGI CD back in the system, and see if I can't replace the samba install. On Mon, 10 Sep 2001, Simon Matter wrote: > Mike Burger schrieb: > > > > Hmm...that probably explains why I can't seem to enable quotas. > > > > What is the version of the quota package that comes with the XFS install? > > The RH-7.1XFS 1.0.1 comes with quota-3.01-pre7 > > Simon > > > > > On Mon, 10 Sep 2001, Simon Matter wrote: > > > > > I've just checked for updates for RH-7.1 and found a new quota RPM. I > > > guess it wouldn't be a good idea to install this one since the quota > > > package for XFS is modified. Did I assume right? > > > > > > Simon > > > > > > > > > > > > From owner-linux-xfs@oss.sgi.com Mon Sep 10 06:43:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8ADhDa16239 for linux-xfs-outgoing; Mon, 10 Sep 2001 06:43:13 -0700 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8ADhBd16220 for ; Mon, 10 Sep 2001 06:43:11 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id f8ADh5J22396 for ; Mon, 10 Sep 2001 06:43:05 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA04238; Tue, 11 Sep 2001 00:41:48 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id AAA87043; Tue, 11 Sep 2001 00:41:48 +1100 (AEDT) Date: Tue, 11 Sep 2001 00:41:47 +1100 From: Nathan Scott To: Simon Matter Cc: linux-xfs Subject: Re: Updated quota RPM for RedHat 7.1 Message-ID: <20010911004147.A288111@wobbly.melbourne.sgi.com> References: <3B9CAB9D.28502B00@ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B9CAB9D.28502B00@ch.sauter-bc.com>; from simon.matter@ch.sauter-bc.com on Mon, Sep 10, 2001 at 02:01:33PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Mon, Sep 10, 2001 at 02:01:33PM +0200, Simon Matter wrote: > I've just checked for updates for RH-7.1 and found a new quota RPM. I > guess it wouldn't be a good idea to install this one since the quota > package for XFS is modified. Did I assume right? With the XFS releases we didn't actually ship a "modified rpm" per-se - we shipped a version of the quota rpm which was ahead of where Redhat was at the time (but it sounds like they are catching up, which is good). I'm pretty sure this new version (as long as its >3.01) will work with XFS quota, but YMMV. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Sep 10 06:45:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8ADj8V16409 for linux-xfs-outgoing; Mon, 10 Sep 2001 06:45:08 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8ADj5d16390 for ; Mon, 10 Sep 2001 06:45:05 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id PAA09205; Mon, 10 Sep 2001 15:44:44 +0200 (CEST) Message-Id: <4.3.2.7.2.20010910154402.03d952c8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Sep 2001 15:44:42 +0200 To: Rob Myers , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: 2.4.9 oops - dual athlon/2gb ram In-Reply-To: <1000127795.10581.13.camel@ransom> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 09:16 10-9-2001 -0400, Rob Myers wrote: >hello > >i generated an oops after running ctcs >(http://sourceforge.net/projects/va-ctcs/) for 5 days. This machine is >a dual athlon with 2gb ram and a single scsi disk. > >Linux version 2.4.9-xfs (root@monsoon) (gcc version 2.96 20000731 (Red >Hat Linux 7.1 2.96-85)) #6 SMP Fri Aug 24 00:31:54 EDT 2001 > >would switching back to kgcc solve this problem? I think it would. Most "vague" problems solve them selves after recompiling with kgcc. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Sep 10 06:50:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8ADou116599 for linux-xfs-outgoing; Mon, 10 Sep 2001 06:50:56 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8ADocd16579; Mon, 10 Sep 2001 06:50:38 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8ADodd16580 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 07:23:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AENFh17426 for linux-xfs-outgoing; Mon, 10 Sep 2001 07:23:15 -0700 Received: from linux.compucomis.net (linux.CompuComIS.net [216.140.122.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AEMpd17406 for ; Mon, 10 Sep 2001 07:22:58 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id E588C139DA; Mon, 10 Sep 2001 10:22:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id E2748139D1; Mon, 10 Sep 2001 10:22:22 -0400 (EDT) Date: Mon, 10 Sep 2001 10:22:22 -0400 (EDT) From: Mike Burger To: Nathan Scott Cc: Simon Matter , linux-xfs Subject: Re: Updated quota RPM for RedHat 7.1 In-Reply-To: <20010911004147.A288111@wobbly.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hmm...the version on my 7.1 w/XFS install is 3.00-4. Maybe I'm missing something. I'll have to check the XFS download area, as well as my XFS install CD. On Tue, 11 Sep 2001, Nathan Scott wrote: > hi, > > On Mon, Sep 10, 2001 at 02:01:33PM +0200, Simon Matter wrote: > > I've just checked for updates for RH-7.1 and found a new quota RPM. I > > guess it wouldn't be a good idea to install this one since the quota > > package for XFS is modified. Did I assume right? > > With the XFS releases we didn't actually ship a "modified rpm" > per-se - we shipped a version of the quota rpm which was ahead > of where Redhat was at the time (but it sounds like they are > catching up, which is good). I'm pretty sure this new version > (as long as its >3.01) will work with XFS quota, but YMMV. > > cheers. > > From owner-linux-xfs@oss.sgi.com Mon Sep 10 07:25:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AEPXY17591 for linux-xfs-outgoing; Mon, 10 Sep 2001 07:25:33 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AEPUd17572 for ; Mon, 10 Sep 2001 07:25:30 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8AEPM519178 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Mon, 10 Sep 2001 07:25:22 -0700 Received: from zeus-fddi.americas.sgi.com ([128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA243469 for ; Mon, 10 Sep 2001 16:25:29 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2917057; Mon, 10 Sep 2001 09:24:03 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA08284; Mon, 10 Sep 2001 09:24:03 -0500 (CDT) Message-ID: <3B9CCCE8.BD8396E9@sgi.com> Date: Mon, 10 Sep 2001 09:23:36 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Alan Brown CC: linux-xfs@oss.sgi.com Subject: Re: Patch comments. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alan Brown wrote: > Also your inclusion of non-related code may interfere with application > of other single patches people may be applying. > Hi Alan - We do have a "clean" set of patches with kdb, lvm, acl/extattr, etc stripped out to make it easy to see "core" XFS. However, even these stripped down patches may not apply cleanly to -ac trees since we do our development against Linus' tree. Also, Alan C. is aware of XFS - although we're not directly submitting to him (I don't think). However, based on some of his diary entries, I'm not sure he's quite ready to take it into his tree either. We'll just keep plugging away... :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Sep 10 07:30:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AEUK817797 for linux-xfs-outgoing; Mon, 10 Sep 2001 07:30:20 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AEU8d17765 for ; Mon, 10 Sep 2001 07:30:08 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id QAA08103; Mon, 10 Sep 2001 16:29:42 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id QAA22982; Mon, 10 Sep 2001 16:29:16 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id F112057306; Mon, 10 Sep 2001 16:28:16 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id DB96125835; Mon, 10 Sep 2001 16:28:16 +0200 (CEST) Message-ID: <3B9CCE00.D704DC0B@ch.sauter-bc.com> Date: Mon, 10 Sep 2001 16:28:16 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Adrian Head Cc: linux-xfs@oss.sgi.com Subject: Re: Problems with many processes copying large directories acrossan XFS volume. References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Adrian Head schrieb: > > Thanks for your reply Simon > > Yes the softraid was fully synced before I started any test. > > The XFS patch I used to obtain these errors was > patch-2.4.9-xfs-2001-08-19 and the errors were: > Sep 9 05:13:46 ATLAS kernel: 02:86: rw=0, want=156092516, limit=360 > Sep 9 05:13:46 ATLAS kernel: attempt to access beyond end of device > > When I used a later version of the XFS patch I had more descriptive > errors written to /var/log/messages: > Sep 10 10:14:57 ATLAS kernel: I/O error in filesystem ("md(9,0)") > meta-data dev 0x900 block 0x9802bdc > Sep 10 10:14:57 ATLAS kernel: (xlog_iodone") error 5 buf count 32768 > Sep 10 10:14:57 ATLAS kernel: xfs_force_shutdown(md(9,0),0x2) called > from line 940 of file xfs_log.c. Return address - 0xd8cb66f8 > Sep 10 10:14:57 ATLAS kernel: Log I/O Error Detected. Shutting down > filesystem: md(9,0) > Sep 10 10:14:57 ATLAS kernel: Please umount the filesystem, and rectify > the problem(s) > Sep 10 10:14:57 ATLAS kernel: xfs_force_shutdown(md(9,0),0x2) called > from line 714 of file xfs_log.c. Return address = 0xd8cb65d3 > Sep 10 10:14:57 ATLAS kernel: attempt to access beyond end of device > Sep 10 10:14:57 ATLAS kernel: 02:82: rw=0, want=1602235696, limit=4 > > I did think at the time that it may have been issues with XFS stomping > all over raid code or raid code stomping all over XFS. Although I not > sure now as the 2.4.10-pre2-xfs-2001-09-02 patch never wrote any errors > out at all. (please see my 2nd post for more info) > > Thanks for taking the time to test this on your own machine. I tried 20, 40 and 80 simultanous cp with no crash. Then I changed the file tree and the new tree has ~280M small files with 100b-50kb size. When using 60 cp jobs the machine died. I could ping it but nothing more. No ssh, no console, no shutdown. I try some more tests tonight. I try the same with ext2 as well to make sure it's XFS and not Softraid. -Simon > > Adrian Head > Bytecomm P/L > > > -----Original Message----- > > From: Simon Matter [SMTP:simon.matter@ch.sauter-bc.com] > > Sent: Monday, 10 September 2001 17:45 > > To: adrian.head@bytecomm.com.au > > Cc: linux-xfs@oss.sgi.com > > Subject: Re: Problems with many processes copying large > > directories across an XFS volume. > > > > Hi Adrian > > > > I did similar tests two months ago. I was having problems as well but > > ufurtunately I don't remember what is was exactly. > > First question: You created Softraid5, was the raid synced when you > > started the tests? > > > > > In the /var/log/messages log around the same time as the copy test I > > get > > > entries like: > > > Sep 9 05:13:46 ATLAS kernel: 02:86: rw=0, want=156092516, limit=360 > > > Sep 9 05:13:46 ATLAS kernel: attempt to access beyond end of device > > > > This looks interesting. I don't know what this means exactly but it > > looks to me like you managed to create a filesystem bigger than the > > raid > > volume was? I got the very same error when I tried to restore data > > with > > xfsrestore from DAT (xfsrestore from DLT was fine). The issue is still > > open. > > > > I have a test system here with SoftRAID5 on 4 U160 SCSI disks. I'll > > try > > to kill it today with cp jobs. > > > > -Simon > > -- Simon Matter Tel: +41 61 695 57 35 Fr.Sauter AG / CIT Fax: +41 61 695 53 30 Im Surinam 55 CH-4016 Basel [mailto:simon.matter@ch.sauter-bc.com] From owner-linux-xfs@oss.sgi.com Mon Sep 10 07:32:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AEWG017932 for linux-xfs-outgoing; Mon, 10 Sep 2001 07:32:16 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AEWCd17910 for ; Mon, 10 Sep 2001 07:32:12 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id HAA02153 for ; Mon, 10 Sep 2001 07:32:19 -0700 (PDT) mail_from (ivanr@melbourne.sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA04422; Tue, 11 Sep 2001 01:30:53 +1100 From: ivanr@melbourne.sgi.com (Ivan Rayner) Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id AAA04860; Tue, 11 Sep 2001 00:30:52 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Tue, 11 Sep 2001 00:30:52 +1000 To: Takayuki Sasaki cc: Subject: Re: xfsdump/xfsrestore failed sometimes when running QA suite 022 In-Reply-To: <200109101246.VAA27978@tagajo.bsd.tnes.nec.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 10 Sep 2001, Takayuki Sasaki wrote: > I would like to know that whether it is correct way or > workaround to dump the XFS file system which requires preceding > unmount and mount, not only for QA suite but also on a > production environment. > > Could you explain me about this? For a production environment, it would not be necessary to do the umount and mount to stabilise the filesystem. The fact is that xfsdump must be run on a mounted filesystem, which means there is always the possibility that it will miss files which have been created immediately before the execution of xfsdump and during the execution of xfsdump. These files will be caught in the backup the next time you run xfsdump. There is nothing xfsdump can do to protect against this situation -- it is up to the system administrator to try to run xfsdump when the system is not busy. If the system is always very busy, then the administrator should be sure to run xfsdump on a regular basis. In the QA environment, we create a test filesystem and immediately dump it, so we need to take special steps to ensure the test works as expected. Basically, it's simply a matter of understanding that the backup created by xfsdump is a snapshot of the filesystem as it was 30 seconds ago[1], rather than the moment xfsdump was run. For most people, I would expect this would be fine. Ivan [1] 30 seconds is just an estimate. This is reliant on the new inode data being being flushed to disk ... I'm not sure how long it takes normally. Someone else on the list might have a better idea. -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Mon Sep 10 07:42:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AEgJv18281 for linux-xfs-outgoing; Mon, 10 Sep 2001 07:42:19 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AEgGd18262 for ; Mon, 10 Sep 2001 07:42:16 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8AEgB521072 for ; Mon, 10 Sep 2001 07:42:11 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2932867; Mon, 10 Sep 2001 09:40:55 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA48024; Mon, 10 Sep 2001 09:40:51 -0500 (CDT) Message-ID: <3B9CD0D7.9D1B0491@sgi.com> Date: Mon, 10 Sep 2001 09:40:23 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Barrett Gay CC: linux-xfs@oss.sgi.com Subject: Re: Kickstart on Bootable CDROM References: <999975773.3b9a6b5d2b4e0@www.c4solutions.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Barrett - Not sure what to tell you here, I have never tried putting the ks.cfg on the CD itself. Might be one for the Red Hat lists/newsgroups? Or has this worked in the past for you with stock RH Linux 7.1? -Eric Barrett Gay wrote: > > I'm trying to create an automated install using kickstart off a bootable cd. > I specify the install method as "cdrom" in my ks.cfg on the cd. When I boot > the cd, it gives me the error: "No install method specified in Kickstart". > However, if I use the same image (with the same kickstart file) on a floppy, > the install goes fine. Any ideas? Should I specify the install method as > Harddrive and point it to /tmp/cdrom? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Sep 10 07:43:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AEh8C18407 for linux-xfs-outgoing; Mon, 10 Sep 2001 07:43:08 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AEh4d18388 for ; Mon, 10 Sep 2001 07:43:04 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8AEgx521171 for ; Mon, 10 Sep 2001 07:42:59 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2905964; Mon, 10 Sep 2001 09:41:40 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA15692; Mon, 10 Sep 2001 09:41:39 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f8AEcXo16558; Mon, 10 Sep 2001 09:38:33 -0500 Message-Id: <200109101438.f8AEcXo16558@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Takayuki Sasaki cc: Timothy Shimmin , linux-xfs@oss.sgi.com Subject: Re: xfsdump/xfsrestore failed sometimes when running QA suite 022 In-Reply-To: Message from Takayuki Sasaki of "Mon, 10 Sep 2001 21:46:58 +0900." <200109101246.VAA27978@tagajo.bsd.tnes.nec.co.jp> Date: Mon, 10 Sep 2001 09:38:33 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > xfsdump uses an xfs feature called bulkstat'ing to speed up > > the stat'ing of all the inodes of the file system. > > However, it apparently snapshots the info from the disk blocks > > instead of going through the in-core data structures. > > This means that if this data is not flushed to disk completely > > when xfsdump is running then it won't have the latest stat > > information. > > Hmmm... I see. > I should expand on this one a little. XFS has two copies of the inode, first the in memory inode structure which is used to by most parts of the filesystem, and is the structure modified by most operations and recorded into the log. Second is the on disk inode structure which is held in buffers, this structure is updated asynchronously from the in memory inode and flushed out to disk. It is this second structure which bulkstat reports the contents of and hence the potential time lag between what is visible to xfsdump and what is visible by the regular system call interface. The contents of the inode buffers should not lag behind the in memory inodes by very much - 30 to 60 seconds with the default kupdated configuration. As Ivan pointed out, xfsdump is not an instantanous operation anyway, it takes time to dump a filesystem, and should the filesystem be changing during the dump process there is no guaranteed way to ensure that everything which existed in memory at the time of the end of the dump will be in the dump. However, everything skipped by one dump should be included in the next dump. Steve From owner-linux-xfs@oss.sgi.com Mon Sep 10 07:46:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AEkEb18601 for linux-xfs-outgoing; Mon, 10 Sep 2001 07:46:14 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AEk6d18579 for ; Mon, 10 Sep 2001 07:46:06 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8AEk1521583 for ; Mon, 10 Sep 2001 07:46:01 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2899790; Mon, 10 Sep 2001 09:44:45 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA87030; Mon, 10 Sep 2001 09:44:45 -0500 (CDT) Message-ID: <3B9CD1C2.FB670E59@sgi.com> Date: Mon, 10 Sep 2001 09:44:18 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: damasta@teknospy.com CC: linux-xfs@oss.sgi.com Subject: Re: Mounting onboard raid References: <200109091603.f89G3NM22280@mail21.jump.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Bryan Payne wrote: > I have 3 harddrives. Hda has a swap, an ext2 boot and a xfs root. Hdb is xfs > and Hdg is xfs. If I attempt to mount hdg1, I get the wrong fs type error. Can you look in the system logs and see what they say when you try to mount? /bin/mount's error messages aren't the most helpful. > However, I moved hdg to to hdb and it mounts fine. Is this because of the > highpoint controller? The funny thing is I can mount hdg as vfat. And can you _read_ it, mounted as vfat? -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Sep 10 07:56:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AEuBD18850 for linux-xfs-outgoing; Mon, 10 Sep 2001 07:56:11 -0700 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AEu9d18831 for ; Mon, 10 Sep 2001 07:56:09 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8AEu3J26089 for ; Mon, 10 Sep 2001 07:56:03 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2931851; Mon, 10 Sep 2001 09:54:48 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA74273; Mon, 10 Sep 2001 09:54:47 -0500 (CDT) Message-ID: <3B9CD41C.89BC0C59@sgi.com> Date: Mon, 10 Sep 2001 09:54:20 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Federico Sevilla III CC: Linux XFS Mailing List Subject: Re: 10minutes for rm -rf on 400MB References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Federico Sevilla III wrote: > > On Sun, 9 Sep 2001 at 13:17, Dirk Wetter wrote: > > a user complained that /rm -rf of 400MB / takes ~10 minutes (!) until > > the command returns, whereas on the systems with reiserfs we have e.g. > > it takes seconds. > > This is expected. XFS does deletes synchronously. Still, 10 minutes is too long, I think. Since you're just guessing about the number of files, though, it's hard to say. If you can find out more about the data, that might offer some hints. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Sep 10 08:03:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AF3bk19124 for linux-xfs-outgoing; Mon, 10 Sep 2001 08:03:37 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AF3Td19097 for ; Mon, 10 Sep 2001 08:03:29 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id IAA18078 for ; Mon, 10 Sep 2001 08:03:33 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA04546; Tue, 11 Sep 2001 02:02:10 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id CAA85507; Tue, 11 Sep 2001 02:02:09 +1100 (AEDT) Date: Tue, 11 Sep 2001 02:02:09 +1100 From: Nathan Scott To: Mike Burger Cc: Simon Matter , linux-xfs Subject: Re: Updated quota RPM for RedHat 7.1 Message-ID: <20010911020209.D288111@wobbly.melbourne.sgi.com> References: <20010911004147.A288111@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mburger@compucomis.net on Mon, Sep 10, 2001 at 10:22:22AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Mon, Sep 10, 2001 at 10:22:22AM -0400, Mike Burger wrote: > Hmm...the version on my 7.1 w/XFS install is 3.00-4. > > Maybe I'm missing something. > > I'll have to check the XFS download area, as well as my XFS install CD. > [Mike] ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/cmd_rpms/ contains quota-3.01-pre7.src.rpm ... that should be the version the installer provides you too. [Simon] Just checked the Redhat 7.1 updates and they are now using the quota-3.01-pre9 code, which does contain XFS quota support. For the next XFS installer release, we will start using the base Redhat quota rpm. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Sep 10 08:18:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AFIW619489 for linux-xfs-outgoing; Mon, 10 Sep 2001 08:18:32 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AFILd19467 for ; Mon, 10 Sep 2001 08:18:21 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA01356 for ; Mon, 10 Sep 2001 08:16:50 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2936810; Mon, 10 Sep 2001 10:17:04 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA92216; Mon, 10 Sep 2001 10:17:04 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f8AFDwM20002; Mon, 10 Sep 2001 10:13:58 -0500 Message-Id: <200109101513.f8AFDwM20002@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Dirk Wetter cc: "Bernhard R. Erdmann" , Linux XFS Mailing List Subject: Re: 10minutes for rm -rf on 400MB In-Reply-To: Message from Dirk Wetter of "Sun, 09 Sep 2001 20:42:51 EDT." <3B9C0C8B.2070201@rentec.com> Content-Transfer-Encoding: 8bit Date: Mon, 10 Sep 2001 10:13:57 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > hi, > > Bernhard R. Erdmann wrote: > > >>we've been running XFS on the data disks of our HPC Linux cluster since > >>a while. we are quite happy with xfs, thx guys for your work! > >>the setup is: > >> > >>- dual >=1GHZ box, 4GB mem > >>- lvm 0.9beta7, phys. volume size ~140 GB, logical vol for xfs: 100GB > >>- no additional mount options or options for mkfs.xfs were given > >>- kernel 2.4.8pre4-xfs, highly patched SuSE 7.0 (not that it should matter) > >> > > >>a user complained that "rm -rf of 400MB" takes ~10 minutes (!) until > >>the > >>command returns, whereas on the systems with reiserfs we have e.g. it > >>takes seconds. > >> > > > >Some very important data is missing: > >- what's the I/O performance of the disk subsystem? > > > why is that relevant? with reiserfs it takes seconds, so the > disks/controller cannot be the bottleneck. This is because of a fundamental difference between reiserfs operation and xfs operation. reiserfs flushes its log to disk periodically, the log could in theory be very large in memory - a crash will basically undo everything which is in the in memory log. In fact, I have seen reiserfs create and remove 30000 files without doing any disk I/O at all. On the other hand XFS has a small in memory log, 64K is the default, when this is full it must go to disk. The in memory log is built of fixed sized 32K buffers, you can add more with the mount option logbufs=x where x is the number allowed, 8 is the maximum. This translates into the number of log writes which can be in transit at anyone time. This small log means that the amount of metadata which update can be lost at a crash is fairly small. To compound this issue some transactions in XFS are always synchronous, freeing space being one of them. The reason for this is complex, say you free some metadata and then it gets reallocated as data - and the data gets flushed out to disk. If you crash at this point and the removal of the space was in a transaction which did not make it out to disk then you end up with a filesystem which has data in an active metadata block. In order to avoid this situation, XFS flushes the free space operation to disk immediately, an expensive operation which is being done to deal with a very rare set of events. The 'obvious' fix is to not reuse this freed space until its transaction is on disk, or to not flush the reallocation to disk until the transaction is on disk. This fix has been on the TODO list around here for quite a long time - but there is always higher priority work to do. Having said that, all is not right with your system. I have a 2 CPU 450 Mhz PIII using a 7200rpm scsi drive on an Adaptec 7896 controller. On a single partition on this machine I just created 3 complete copies of the xfs tree, (kernel and commands) this consisted of 34549 files occupying 500Mbytes of disk space. In order to clean the cache and force reads from disk in the remove process I unmounted and remounted the filesystem before removing it. It took 65.373 seconds to remove the whole directory tree with a single rm -r -f. Having said that, this filesystem was mounted with 8 log buffers, and has a 16384 block log. The mkfs option for creating a bigger log is: mkfs -t xfs -f -l size=16384b /dev/xxx Steve From owner-linux-xfs@oss.sgi.com Mon Sep 10 08:20:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AFKS819625 for linux-xfs-outgoing; Mon, 10 Sep 2001 08:20:28 -0700 Received: from cis.ohio-state.edu (root@mail.cis.ohio-state.edu [164.107.115.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AFKPd19606 for ; Mon, 10 Sep 2001 08:20:25 -0700 Received: from iota.cis.ohio-state.edu (ramakria@iota.cis.ohio-state.edu [164.107.112.17]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id LAA00699 for ; Mon, 10 Sep 2001 11:20:24 -0400 (EDT) Received: from localhost (ramakria@localhost) by iota.cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id LAA05987 for ; Mon, 10 Sep 2001 11:20:24 -0400 (EDT) X-Authentication-Warning: iota.cis.ohio-state.edu: ramakria owned process doing -bs Date: Mon, 10 Sep 2001 11:20:24 -0400 (EDT) From: Arun Ramakrishnan To: Linux XFS Mailing List Subject: Re: 10minutes for rm -rf on 400MB In-Reply-To: <3B9CD41C.89BC0C59@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I recently did rm -rf on a directory containing 6 10 GB files and it took a few seconds.I am running the XFS patched 2.4.9 kernel. Cheers, Arun. On Mon, 10 Sep 2001, Eric Sandeen wrote: > Federico Sevilla III wrote: > > > > On Sun, 9 Sep 2001 at 13:17, Dirk Wetter wrote: > > > a user complained that /rm -rf of 400MB / takes ~10 minutes (!) until > > > the command returns, whereas on the systems with reiserfs we have e.g. > > > it takes seconds. > > > > This is expected. XFS does deletes synchronously. > > Still, 10 minutes is too long, I think. Since you're just guessing > about the number of files, though, it's hard to say. If you can find > out more about the data, that might offer some hints. > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > From owner-linux-xfs@oss.sgi.com Mon Sep 10 08:21:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AFL3019751 for linux-xfs-outgoing; Mon, 10 Sep 2001 08:21:03 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AFKbd19727; Mon, 10 Sep 2001 08:20:37 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8AFKcd19728 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 08:41:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AFfqL20231 for linux-xfs-outgoing; Mon, 10 Sep 2001 08:41:52 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AFfnd20212 for ; Mon, 10 Sep 2001 08:41:49 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8AFfh528112 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Mon, 10 Sep 2001 08:41:43 -0700 Received: from zeus-fddi.americas.sgi.com ([128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id RAA255488 for ; Mon, 10 Sep 2001 17:41:50 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2932434; Mon, 10 Sep 2001 10:40:25 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA80454; Mon, 10 Sep 2001 10:40:24 -0500 (CDT) Message-ID: <3B9CDECC.2EC34A61@sgi.com> Date: Mon, 10 Sep 2001 10:39:56 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Martin Loschwitz CC: linux-xfs@oss.sgi.com Subject: Re: xfs-cvstree-errors References: <20010910150620.A2155@Minerva> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Martin Loschwitz wrote: > > Hello ppl, i downloaded your xfs-cvs-tree for Linux-kernel 2.4. I tried to > compile it, but when i do "make dep", it finishs with: > > (problems) A fresh checkout today Works For Me. You might try a "make mrproper" and give it another shot. Or maybe even try a fresh checkout? -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Sep 10 09:02:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AG2C220728 for linux-xfs-outgoing; Mon, 10 Sep 2001 09:02:12 -0700 Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AG29d20709 for ; Mon, 10 Sep 2001 09:02:09 -0700 Received: from scare ([63.231.179.33]) by lips.thebarn.com (8.12.0/8.12.0) with ESMTP id f8AG1uPp028834; Mon, 10 Sep 2001 11:01:56 -0500 (CDT) Subject: Re: ftp.thebarn.com From: Russell Cattelan To: Alan Eldridge Cc: SGI XFS Dev List In-Reply-To: <20010909180634.A14095@wwweasel.geeksrus.net> References: <20010909180634.A14095@wwweasel.geeksrus.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 10 Sep 2001 10:55:15 -0500 Message-Id: <1000137316.29096.4678.camel@scare> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 09 Sep 2001 18:06:34 -0400, Alan Eldridge wrote: > Is Russell's CVSup daemon dead? Or is something else wrong? I can traceroute it > but I can't do a CVSup connect. :( > the system drive failed over the weekend and I was out of town this weekend so I didn't notice the failure till late sunday. I'm working on recovering the configuration give me a few hours. > -- > Alan Eldridge > from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Mon Sep 10 09:34:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AGYXo21343 for linux-xfs-outgoing; Mon, 10 Sep 2001 09:34:33 -0700 Received: from roujin.gargoylecc.com (roujin.gargoylecc.com [65.100.85.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AGYNd21323 for ; Mon, 10 Sep 2001 09:34:24 -0700 Received: from ringram by roujin.gargoylecc.com with local (Exim 3.31 #1) id 15gPWF-0000e8-00 for linux-xfs@oss.sgi.com; Mon, 10 Sep 2001 11:46:27 +0000 Date: Mon, 10 Sep 2001 11:46:27 +0000 To: linux-xfs@oss.sgi.com Subject: xfsdump error question Message-ID: <20010910114627.A1640@roujin.gargoylecc.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline User-Agent: Mutt/1.3.20i From: Russel Ingram Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm trying to run a system backup on my Debian based XFS system with xfsdump and keep getting the following error: xfsdump: version 3.0 - Running single-threaded xfsdump: level 0 dump of roujin:/ xfsdump: dump date: Mon Sep 10 09:41:26 2001 xfsdump: session id: 8714af3d-1288-46a3-ac9c-37ed6a33639c xfsdump: session label: "roujin full" xfsdump: ino map phase 1: skipping (no subtrees specified) xfsdump: ino map phase 2: constructing initial dump list xfsdump: ERROR: map_add(5243008, 3): ino(5243008) <= last_ino(5768702) The command I'm using is: xfsdump -l0 -o -E -F -L"roujin full" -M"root" -f /dev/st0 / Can someone tell me what this error means and if its something I'm doing wrong or if its a problem with my filesystem or xfsdump? I've also attached the output from running the same command with -v5. Thanx, Russ -- Russel H. Ingram Gargoyle Computer Consulting (307)742-1361 or (307)760-1317 www.gargoylecc.com --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfsdump.err" xfsdump: RLIMIT_AS org cur 0xffffffffffffffff max 0xffffffffffffffff xfsdump: RLIMIT_STACK org cur 0x800000 max 0xffffffffffffffff xfsdump: raising stack size soft limit from 0x800000 to 0x2000000 xfsdump: RLIMIT_STACK new cur 0x2000000 max 0xffffffffffffffff xfsdump: RLIMIT_DATA org cur 0xffffffffffffffff max 0xffffffffffffffff xfsdump: RLIMIT_FSIZE org cur 0xffffffffffffffff max 0xffffffffffffffff xfsdump: RLIMIT_FSIZE now cur 0xffffffffffffffff max 0xffffffffffffffff xfsdump: RLIMIT_CPU cur 0xffffffffffffffff max 0xffffffffffffffff xfsdump: RLIMIT_CPU now cur 0xffffffffffffffff max 0xffffffffffffffff xfsdump: INTGENMAX == 2147483647 (0x7fffffff) xfsdump: UINTGENMAX == 4294967295 (0xffffffff) xfsdump: OFF64MAX == 9223372036854775807 (0x7fffffffffffffff) xfsdump: OFFMAX == -1 (0x7fffffff) xfsdump: SIZEMAX == 4294967295 (0xffffffff) xfsdump: INOMAX == 4294967295 (0xffffffff) xfsdump: TIMEMAX == 2147483647 (0x7fffffff) xfsdump: SIZE64MAX == 18446744073709551615 (0xffffffffffffffff) xfsdump: INO64MAX == 18446744073709551615 (0xffffffffffffffff) xfsdump: UINT64MAX == 18446744073709551615 (0xffffffffffffffff) xfsdump: INT64MAX == 9223372036854775807 (0x7fffffffffffffff) xfsdump: UINT32MAX == 4294967295 (0xffffffff) xfsdump: INT32MAX == 2147483647 (0x7fffffff) xfsdump: INT16MAX == 32767 (0x7fff) xfsdump: UINT16MAX == 65535 (0xffff) xfsdump: getpagesize( ) returns 4096 xfsdump: parent pid is 1621 xfsdump: effective user id is 0 xfsdump: stack pid 1621: sz 0x2000000 min 0xbdfffbab max 0xbffffbab xfsdump: instantiating drive_scsitape xfsdump: version 3.0 - Running single-threaded xfsdump: fs / uuid [85dc0a65-d803-485b-9142-ef2c75e9dca9] xfsdump: creating directory /var/xfsdump xfsdump: level 0 dump of roujin:/ xfsdump: dump date: Mon Sep 10 11:31:41 2001 xfsdump: session id: 912bd615-dffe-453d-abe2-22e6ae42dbe4 xfsdump: session label: "root" xfsdump: excluding /var/xfsdump from dump xfsdump: excluding /var/xfsdump/inventory from dump xfsdump: excluding /var/xfsdump/inventory/3552fb6a-10ed-48eb-830c-3e32d0ea895c.InvIndex from dump xfsdump: excluding /var/xfsdump/inventory/823b26df-0abb-42d8-9d6b-8cd3fc826936.StObj from dump xfsdump: excluding /var/xfsdump/inventory/fstab from dump xfsdump: ino map phase 1: skipping (no subtrees specified) xfsdump: ino map phase 2: constructing initial dump list xfsdump: bulkstat iteration initiated: start_ino == 0 xfsdump: calling bulkstat xfsdump: bulkstat returns buflen 4096 ino 128 xfsdump: calling bulkstat xfsdump: bulkstat returns buflen 4096 ino 161396 xfsdump: calling bulkstat xfsdump: bulkstat returns buflen 4096 ino 1077258 xfsdump: calling bulkstat xfsdump: bulkstat returns buflen 4096 ino 1245314 xfsdump: calling bulkstat xfsdump: bulkstat returns buflen 4096 ino 1589835 xfsdump: calling bulkstat xfsdump: bulkstat returns buflen 4096 ino 2196064 xfsdump: calling bulkstat xfsdump: bulkstat returns buflen 4096 ino 3256808 xfsdump: calling bulkstat xfsdump: bulkstat returns buflen 4096 ino 3426415 xfsdump: calling bulkstat xfsdump: bulkstat returns buflen 4096 ino 3677526 xfsdump: calling bulkstat xfsdump: bulkstat returns buflen 4096 ino 4394016 xfsdump: calling bulkstat xfsdump: bulkstat returns buflen 4096 ino 5282011 xfsdump: ino 5768703 needed second bulkstat xfsdump: ERROR: map_add(5243008, 3): ino(5243008) <= last_ino(5768702) --bg08WKrSYDhXBjb5-- From owner-linux-xfs@oss.sgi.com Mon Sep 10 09:41:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AGfvj21595 for linux-xfs-outgoing; Mon, 10 Sep 2001 09:41:57 -0700 Received: from phobos.pop-star.net (phobos.pop-star.net [64.85.83.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AGfsd21575 for ; Mon, 10 Sep 2001 09:41:54 -0700 Received: from zerowing.pop-star.net ([208.181.22.52]) by phobos.pop-star.net with asmtp (Exim 3.167 #4) id 15gU9q-0000c2-00 for linux-xfs@oss.sgi.com; Mon, 10 Sep 2001 09:43:38 -0700 Subject: Contrib 2.4.10-pre2 RPMS From: Andy Kwong To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.13.99+cvs.2001.09.05.07.08 (Preview Release) Date: 10 Sep 2001 09:42:18 -0700 Message-Id: <1000140142.9874.9.camel@zerowing.pop-star.net> Mime-Version: 1.0 X-Authenticated-Sender: andy.kwong@pop-star.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, We are using XFS with RedHat on production systems with highmem. Seems like the 2.4.3 and 2.4.5 had bounce buffer issues. Thus, we made some 2.4.10-pre2 RPMS with lm_sensors support (and the PL2303 patch) for convenience. They are available at - http://rpms.aicompro.net/ These are derived from the 2.4.5 RPM spec file and come in devfs and non-devfs flavors. Cheers, Andy From owner-linux-xfs@oss.sgi.com Mon Sep 10 09:44:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AGi3l21731 for linux-xfs-outgoing; Mon, 10 Sep 2001 09:44:03 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AGhud21712; Mon, 10 Sep 2001 09:43:56 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8AGhvd21713 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 10:50:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AHoiK22767 for linux-xfs-outgoing; Mon, 10 Sep 2001 10:50:44 -0700 Received: from thor.goeci.com (thor.goeci.com [216.181.40.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AHoed22748 for ; Mon, 10 Sep 2001 10:50:40 -0700 Received: by THOR with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Sep 2001 13:50:34 -0400 Message-ID: From: Murthy Kambhampaty To: "'linux-xfs@oss.sgi.com'" Subject: Installing on disks connected with 3ware adapter Date: Mon, 10 Sep 2001 13:50:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am trying to install from the XFS installer (1.0.1) to a RAID 5 array on the 3ware Escalade 7810 controller. I load the drivers from floppy, but the installer doesn't not see the drives. I do not experience this problem with the stock RedHat installer CD-ROM. Please help. 3ware's installation manual is at: http://www.3ware.com/support/UserDocs/7000UG1.pdf Linux installation directions begin on page 107 3ware's drivers can be downloaded at: http://www.3ware.com/support/swlibrary.asp Thanks for the help. In the meanwhile, I am trying to see if using the older 1.0.0 installer give success. I will e-mail my findings with the subject above preceded by "Follow up:" Murthy S. Murthy Kambhampaty Vice President Glassman-Oliver Economic Consultants, Inc. 1828 L St NW, Suite 405 Washington, DC 20036-5104 Voice (202) 331-1946 Fax (202) 466-3199 From owner-linux-xfs@oss.sgi.com Mon Sep 10 10:57:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AHvuk22976 for linux-xfs-outgoing; Mon, 10 Sep 2001 10:57:56 -0700 Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AHvqd22942 for ; Mon, 10 Sep 2001 10:57:52 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id 2CBCE139E5; Mon, 10 Sep 2001 13:57:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id 29CA1139DA; Mon, 10 Sep 2001 13:57:55 -0400 (EDT) Date: Mon, 10 Sep 2001 13:57:55 -0400 (EDT) From: Mike Burger To: Nathan Scott Cc: Simon Matter , linux-xfs Subject: Re: Updated quota RPM for RedHat 7.1 In-Reply-To: <20010911020209.D288111@wobbly.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yup...just ran the update. Now, I'm working on creating the quotas...unfortunately, Webmin can't manipulate them...it's looking for quota.user and/or aquota.user, which don't exist in XFS quota support. Webmin thinks that the quota system isn't enabled. Oh, well. On Tue, 11 Sep 2001, Nathan Scott wrote: > hi, > > On Mon, Sep 10, 2001 at 10:22:22AM -0400, Mike Burger wrote: > > Hmm...the version on my 7.1 w/XFS install is 3.00-4. > > > > Maybe I'm missing something. > > > > I'll have to check the XFS download area, as well as my XFS install CD. > > > > [Mike] > ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/cmd_rpms/ > contains quota-3.01-pre7.src.rpm ... that should be the version > the installer provides you too. > > [Simon] > Just checked the Redhat 7.1 updates and they are now using the > quota-3.01-pre9 code, which does contain XFS quota support. > For the next XFS installer release, we will start using the > base Redhat quota rpm. > > cheers. > > From owner-linux-xfs@oss.sgi.com Mon Sep 10 11:02:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AI2Xw23187 for linux-xfs-outgoing; Mon, 10 Sep 2001 11:02:33 -0700 Received: from cis.ohio-state.edu (root@mail.cis.ohio-state.edu [164.107.115.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AI2Sd23168 for ; Mon, 10 Sep 2001 11:02:28 -0700 Received: from iota.cis.ohio-state.edu (ramakria@iota.cis.ohio-state.edu [164.107.112.17]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id OAA28441; Mon, 10 Sep 2001 14:02:27 -0400 (EDT) Received: from localhost (ramakria@localhost) by iota.cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id OAA07330; Mon, 10 Sep 2001 14:02:26 -0400 (EDT) X-Authentication-Warning: iota.cis.ohio-state.edu: ramakria owned process doing -bs Date: Mon, 10 Sep 2001 14:02:26 -0400 (EDT) From: Arun Ramakrishnan To: Murthy Kambhampaty cc: "'linux-xfs@oss.sgi.com'" Subject: Re: Installing on disks connected with 3ware adapter In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I beleive that the 3ware support comes with the 2.4 kernel.I had lot of kernel oopses with the 2.4 kernel and the drivers.So i checked the "3ware kernel switch" while compiling the kernel and it has been working fine. Cheers, Arun On Mon, 10 Sep 2001, Murthy Kambhampaty wrote: > I am trying to install from the XFS installer (1.0.1) to a RAID 5 array on > the 3ware Escalade 7810 controller. I load the drivers from floppy, but the > installer doesn't not see the drives. I do not experience this problem with > the stock RedHat installer CD-ROM. Please help. > > 3ware's installation manual is at: > http://www.3ware.com/support/UserDocs/7000UG1.pdf > Linux installation directions begin on page 107 > > 3ware's drivers can be downloaded at: > http://www.3ware.com/support/swlibrary.asp > > Thanks for the help. In the meanwhile, I am trying to see if using the older > 1.0.0 installer give success. I will e-mail my findings with the subject > above preceded by "Follow up:" > > Murthy > > S. Murthy Kambhampaty > Vice President > Glassman-Oliver Economic Consultants, Inc. > 1828 L St NW, Suite 405 > Washington, DC 20036-5104 > Voice (202) 331-1946 > Fax (202) 466-3199 > From owner-linux-xfs@oss.sgi.com Mon Sep 10 11:07:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AI7cj23366 for linux-xfs-outgoing; Mon, 10 Sep 2001 11:07:38 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AI7Hd23338; Mon, 10 Sep 2001 11:07:17 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8AI7Id23340 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 11:09:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AI9LZ23500 for linux-xfs-outgoing; Mon, 10 Sep 2001 11:09:21 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AI9Dd23481 for ; Mon, 10 Sep 2001 11:09:13 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA04610 for ; Mon, 10 Sep 2001 11:08:44 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2769637; Mon, 10 Sep 2001 13:07:13 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA97787; Mon, 10 Sep 2001 13:07:12 -0500 (CDT) Message-ID: <3B9D0134.CABAF90F@sgi.com> Date: Mon, 10 Sep 2001 13:06:44 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Murthy Kambhampaty CC: "'linux-xfs@oss.sgi.com'" Subject: Re: Installing on disks connected with 3ware adapter References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Murthy Kambhampaty wrote: > > I am trying to install from the XFS installer (1.0.1) to a RAID 5 array on > the 3ware Escalade 7810 controller. I load the drivers from floppy, but the > installer doesn't not see the drives. I do not experience this problem with > the stock RedHat installer CD-ROM. Please help. Hi - I'm not sure how you created the drivers floppy - if it's the same one you used with RH Linux 7.1, it won't work with the XFS installer since we run a different (xfs-capable, 2.4.3-updated) kernel in our installer. You'll need to recompile the driver to be loadable under the 2.4.3-BOOT kernel we use in the installer. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Sep 10 11:17:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AIH1B23790 for linux-xfs-outgoing; Mon, 10 Sep 2001 11:17:01 -0700 Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [195.124.129.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AIGwd23771 for ; Mon, 10 Sep 2001 11:16:58 -0700 Received: from warp9.koschikode.com (pD9E0E640.dip.t-dialin.net [217.224.230.64]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id A0CFCB52B; Mon, 10 Sep 2001 20:16:53 +0200 (CEST) Received: from koschikode.com (kaplah.koschikode.com [192.168.200.15]) by warp9.koschikode.com (Postfix) with ESMTP id 846D7CDF3; Mon, 10 Sep 2001 20:16:42 +0200 (CEST) Message-ID: <3B9D0389.CE17E423@koschikode.com> Date: Mon, 10 Sep 2001 20:16:41 +0200 From: Juri Haberland X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10-pre4-ext3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Seref Tufan Sen Cc: linux-xfs@oss.sgi.com, Michael Wahlbrink Subject: Re: Problems with many processes copying large directories across an XFS volume.[Offtpic] References: <001201c139f7$5d5b62a0$2c054ba0@aontws4044> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seref Tufan Sen wrote: > > I got 7 copies of this message. Am I the only one with this problem ??? No, same here :-( Michael, it seems to be your message which is repeatedly send (~ ever 90 minutes). Can you have a look whether there's something wrong on your side? TIA, Juri From owner-linux-xfs@oss.sgi.com Mon Sep 10 12:37:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AJbmt25498 for linux-xfs-outgoing; Mon, 10 Sep 2001 12:37:48 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AJbHd25387; Mon, 10 Sep 2001 12:37:17 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8AJbId25398 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 13:35:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AKZgq26807 for linux-xfs-outgoing; Mon, 10 Sep 2001 13:35:42 -0700 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AKZbd26782 for ; Mon, 10 Sep 2001 13:35:37 -0700 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com. [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id QAA13446; Mon, 10 Sep 2001 16:35:00 -0400 Message-ID: <3B9D2415.DE0F8347@ieee.org> Date: Mon, 10 Sep 2001 16:35:33 -0400 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Murthy Kambhampaty , "'linux-xfs@oss.sgi.com'" Subject: Re: Installing on disks connected with 3ware adapter References: <3B9D0134.CABAF90F@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > I'm not sure how you created the drivers floppy - if it's the same one > you used with RH Linux 7.1, it won't work with the XFS installer since > we run a different (xfs-capable, 2.4.3-updated) kernel in our > installer. You'll need to recompile the driver to be loadable under the > 2.4.3-BOOT kernel we use in the installer. I had the same issue. This is what I did: - Install RedHat 7.1 + XFS 1.0.1 on a regular drive - Grab the updated firmware and drivers for the 7000 series - Compile the driver module for the kernel, copy to modules directory - Create an initrd (initial root disk) for the kernel with the 3Ware driver - Modify and re-install LILO for the kernel+initrd - Reboot with 3Ware card/drives connected - Transfer over the partitions - Boot the XFS installer into recovery mode - Re-install LILO I found this to be quickest and easiest. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com From owner-linux-xfs@oss.sgi.com Mon Sep 10 13:43:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AKhIS27115 for linux-xfs-outgoing; Mon, 10 Sep 2001 13:43:18 -0700 Received: from gateway1.brets.elevating.com (adsl-216-63-236-137.dsl.tulsok.swbell.net [216.63.236.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AKhCd27096 for ; Mon, 10 Sep 2001 13:43:12 -0700 Received: from elevating.com (bretdell.brets.elevating.com [192.168.0.128]) by gateway1.brets.elevating.com (8.9.3/8.8.7) with ESMTP id PAA13696; Mon, 10 Sep 2001 15:43:12 -0500 Message-ID: <3B9D25E0.9483C32A@elevating.com> Date: Mon, 10 Sep 2001 15:43:12 -0500 From: Bret Hughes X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en, ja MIME-Version: 1.0 To: linux-xfs Subject: [Fwd: Re: directory cache problems (I think)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter wrote: > > Hi Bret > > Bret Hughes schrieb: > > > > I have a configuration on 6 boxes, Duron 700 with 128 MB ram and 10GB > > ide harddrives. These machines are all XFS 1.0.1 using the kernel from > > the 1.0.1 RH install iso and most of the RH updates. > > > > They were all placed into service the same day and yesterday 5 days > > after they were turned on they all stopped responding to ssh. A couple > > would still respond to a ping but nothing else. Actually I caough one > > before it quit altogether and rebooted it last night. These machines a > > kiosk type display that scroll html and flash pages using (netscape as > > the browser). There is no user interaction infact not any input device > > at all. A different page is displayed every 10 seconds. > > > > Now, After rebooting them I can get to the sadc data and looking through > > the logs shows really bad stuff happening at 1:00PM yesterday on the one > > machine I have really looked at closely. interrupt 14s out the wazoo > > and what I think must be the cause, the dentunusd goes to 0. Looking > > over the logs of the last few days I can see the dentunusd creeping down > > from the beginning at boot of over 20K to 0. > > > > Since netscape is such a pig I kill it and restart it once an hour and > > restart X once a day. both these events seem to take a tremendous toll > > on this value and never gain it all back. > > > > I don't know if this is an XFS issue or not but I thought that I would > > start here. Any ideas? I can send all the log data anyone might use if > > it would help. Right now I am going to reboot the damn things nightly > > like they were windows machines for Christ's sake. > > > > BTW the same scenario and control scripts run for months on end on RH > > 6.2 using the 2.2.3-16 kernel. > > > > Any tips and or other places to ask are appreciated. > > > > TIA > > > > Bret > > Did you run the RH-6.2 stuff on exactly the same hardware (including > same disks?) No, I have not. The load is really not very high though. I will go ahead and try the 6.2 config on the new hardware. Something is definitely weird. > > What about the disks, are they running with DMA enabled? > Yes. the default was to enable mda and the 32 bit access. I have not increased the bus speed though I plan on testing it. > Over here our mailservers used to be IBM PC's with Fujitsu Harddrives. > After some time of operation they started to slow down and load started > to increase. They even did not respond to ssh sometimes. In the end I > saw that those disks failed under the heavy load of the mailserver and I > replaced them with other disks. We have hundreds of the same disks in > windows desktop PC's with no problem. Linux just pushes the hardware > more. > > Simon Thanks for the thoughts. Bret From owner-linux-xfs@oss.sgi.com Mon Sep 10 14:00:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AL0nv27836 for linux-xfs-outgoing; Mon, 10 Sep 2001 14:00:49 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AL0bd27809; Mon, 10 Sep 2001 14:00:37 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8AL0cd27810 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 15:24:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AMO3L30339 for linux-xfs-outgoing; Mon, 10 Sep 2001 15:24:03 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AMNvd30319; Mon, 10 Sep 2001 15:23:57 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8AMNwd30320 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 15:47:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AMlph30944 for linux-xfs-outgoing; Mon, 10 Sep 2001 15:47:51 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AMlOd30919; Mon, 10 Sep 2001 15:47:25 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8AMlPd30920 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 16:42:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8ANgIW31884 for linux-xfs-outgoing; Mon, 10 Sep 2001 16:42:18 -0700 Received: from plato.arts.usyd.edu.au (plato.arts.usyd.edu.au [129.78.16.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8ANgBd31850 for ; Mon, 10 Sep 2001 16:42:12 -0700 Received: from arts.usyd.edu.au (IDENT:matthew@whitestar.arts.usyd.edu.au [129.78.16.20]) by plato.arts.usyd.edu.au (8.9.3/8.9.3) with ESMTP id JAA00945; Tue, 11 Sep 2001 09:41:24 +1000 (EST) Message-ID: <3B9D5124.3C1F644D@arts.usyd.edu.au> Date: Tue, 11 Sep 2001 09:47:48 +1000 From: Matthew Geier Organization: Arts IT Unit, Sydney University X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7-pre6-xfs i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: Simon Matter CC: linux-xfs Subject: Re: Updated quota RPM for RedHat 7.1 References: <3B9CAB9D.28502B00@ch.sauter-bc.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms3D1C4854A0DB9000FEF4AFB7" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms3D1C4854A0DB9000FEF4AFB7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Simon Matter wrote: > > I've just checked for updates for RH-7.1 and found a new quota RPM. I > guess it wouldn't be a good idea to install this one since the quota > package for XFS is modified. Did I assume right? Yes. I accidently did this running the command line 'up2date' which doesn't ask what packages to update, it just 'does it'. Fortunatly I had the XFS source tree including the 'cmd' folder on the system, so I had the XFS versions on hand to put back :-) -- Matthew Geier matthew@arts.usyd.edu.au Arts IT Unit +61 2 9351 4713 Sydney University --------------ms3D1C4854A0DB9000FEF4AFB7 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH0AYJKoZIhvcNAQcCoIIHwTCCB70CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BbswggKKMIIB86ADAgECAgMFMYswDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTA3MDkxOTEyNThaFw0wMjA3MDkxOTEyNTha MEoxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxJzAlBgkqhkiG9w0BCQEWGG1h dHRoZXdAYXJ0cy51c3lkLmVkdS5hdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1H+o MQ4xn5lDS/7p9rYboPW7grw13lXOj7Xisip37QttkX7Ga3ITBXnsAKnuFK3Z7GtILACBXil1 BngLBOd0AlW9zqQBXEOP9aODNJzBsTb3+tOHwQo6shcORKQArKEinG00SuwBdzxALU3KWT6E yIUSvoz7q0PN4C8qUF3t00sCAwEAAaM1MDMwIwYDVR0RBBwwGoEYbWF0dGhld0BhcnRzLnVz eWQuZWR1LmF1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAiJu7SNBXsW7I+ZH9 e2+0M47BmR3DxV31VbW9mKcwuamusWSJJEy5MAKZc8b0snRX/XDkCpM+av3VxDJX8T3rxOE0 siyCC6Tclu6wjwjw0goXK4N6Xhsz+qwIfdoclNZkqK5yInEZtc5ijKr0IPRgch79f35WP82C SNHVYApmjzgwggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoT EVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERp dmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG 9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcN MDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmlj YXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNE KYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu 2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQAB o04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0T AQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0 S1liiu1EvknH6A27j7kNaiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHC CafvS65y3QZn9VBvLli4tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+p lrgFPFL83eliA0gxggHdMIIB2QIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNV BAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMFMYswCQYFKw4DAhoFAKCBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMTA5MTAyMzQ3NDlaMCMGCSqGSIb3DQEJBDEWBBShRI1k v9L/tOJ1TF7s+C7K5ybQ6TA6BgkqhkiG9w0BCQ8xLTArMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBgkqhkiG9w0BAQEFAASBgETvrK6p2jj34wo/jgr5 RxnTJMmuMtyftXprGqE/rBwRTf3hGENNoHi61NnHVIG+632h7e6htqR/QTYSSzUM97/yTacC d8+C9vQOukbVTi959W4zt/rdhTpDPhtnWfHyqsfjIRtEkmIIjS2j24SOQsxU6O2PMt9PLD7J XaOs3Dce --------------ms3D1C4854A0DB9000FEF4AFB7-- From owner-linux-xfs@oss.sgi.com Mon Sep 10 16:42:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8ANg9E31844 for linux-xfs-outgoing; Mon, 10 Sep 2001 16:42:09 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8ANg3d31823 for ; Mon, 10 Sep 2001 16:42:03 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA01248 for ; Mon, 10 Sep 2001 16:42:07 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA06602; Tue, 11 Sep 2001 10:40:40 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA29557; Tue, 11 Sep 2001 10:40:37 +1100 (AEDT) Date: Tue, 11 Sep 2001 10:40:36 +1100 From: Nathan Scott To: Mike Burger Cc: linux-xfs , jcameron@webmin.com Subject: Re: Updated quota RPM for RedHat 7.1 Message-ID: <20010911104036.B376776@wobbly.melbourne.sgi.com> References: <20010911020209.D288111@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mburger@compucomis.net on Mon, Sep 10, 2001 at 01:57:55PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Mike, On Mon, Sep 10, 2001 at 01:57:55PM -0400, Mike Burger wrote: > Yup...just ran the update. Now, I'm working on creating the > quotas...unfortunately, Webmin can't manipulate them...it's looking for > quota.user and/or aquota.user, which don't exist in XFS quota support. > Webmin thinks that the quota system isn't enabled. > Hmmm.... I know nothing about Webmin I'm afraid. The quota link from this web page - http://www.webmin.com/webmin/standard.html - suggests its a matter of doing some Perl hacking to make this work. I've CC'd the webmin author - perhaps he can give some additional pointers. I'm guessing there's an assumption in there that for quota to be enabled there must be a [a]quota.[user|group] file in the filesystem root - which is not correct for XFS filesystems. As a reference, there is a "README.quota" file in xfsprogs which discusses the differences between XFS notion of quota and the model used in the two versions of the Linux VFS quota subsystem. Another reference is the code in the current quota package which implements support for all three models of quota in one set of tools. cheers. > > On Tue, 11 Sep 2001, Nathan Scott wrote: > > > hi, > > > > On Mon, Sep 10, 2001 at 10:22:22AM -0400, Mike Burger wrote: > > > Hmm...the version on my 7.1 w/XFS install is 3.00-4. > > > > > > Maybe I'm missing something. > > > > > > I'll have to check the XFS download area, as well as my XFS install CD. > > > > > > > [Mike] > > ftp://oss.sgi.com/projects/xfs/download/Release-1.0.1/cmd_rpms/ > > contains quota-3.01-pre7.src.rpm ... that should be the version > > the installer provides you too. > > > > [Simon] > > Just checked the Redhat 7.1 updates and they are now using the > > quota-3.01-pre9 code, which does contain XFS quota support. > > For the next XFS installer release, we will start using the > > base Redhat quota rpm. > > > > cheers. > > > > > -- Nathan From owner-linux-xfs@oss.sgi.com Mon Sep 10 17:02:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B02ur32386 for linux-xfs-outgoing; Mon, 10 Sep 2001 17:02:56 -0700 Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B02sd32364 for ; Mon, 10 Sep 2001 17:02:54 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id EE74E139EC; Mon, 10 Sep 2001 20:02:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id EB857139EA; Mon, 10 Sep 2001 20:02:57 -0400 (EDT) Date: Mon, 10 Sep 2001 20:02:57 -0400 (EDT) From: Mike Burger To: Matthew Geier Cc: Simon Matter , linux-xfs Subject: Re: Updated quota RPM for RedHat 7.1 In-Reply-To: <3B9D5124.3C1F644D@arts.usyd.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 11 Sep 2001, Matthew Geier wrote: > I accidently did this running the command line 'up2date' which doesn't > ask what packages to update, it just 'does it'. > Fortunatly I had the XFS source tree including the 'cmd' folder on the > system, so I had the XFS versions on hand to put back :-) Interesting...usually, when I run "up2date" from the command line, it gives me a menu. I usually have to run "up2date -l" to list the packages that are available, and then "up2date ..." to download and install them. From owner-linux-xfs@oss.sgi.com Mon Sep 10 17:11:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B0BAL32668 for linux-xfs-outgoing; Mon, 10 Sep 2001 17:11:10 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B0Ahd32642; Mon, 10 Sep 2001 17:10:43 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8B0Aid32643 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 18:12:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B1CxB01429 for linux-xfs-outgoing; Mon, 10 Sep 2001 18:12:59 -0700 Received: from alpha.bytecomm.com.au (byt130674-1.gw.connect.com.au [202.21.11.108]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B1Crd01407 for ; Mon, 10 Sep 2001 18:12:53 -0700 Received: (qmail 24466 invoked from network); 11 Sep 2001 01:12:41 -0000 Received: from unknown (HELO herbie.local) (192.168.0.11) by 192.168.0.1 with SMTP; 11 Sep 2001 01:12:41 -0000 Received: by herbie.local with Internet Mail Service (5.5.1960.3) id ; Tue, 11 Sep 2001 11:12:41 +1000 Message-ID: From: Adrian Head To: Simon Matter Cc: linux-xfs@oss.sgi.com Subject: RE: Problems with many processes copying large directories across an XFS volume. Date: Tue, 11 Sep 2001 11:12:35 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Again - thanks Simon for your time. I have done ten's of tests now and I am getting a strong feeling that it is the same problems described here from Steve Lord: http://marc.theaimsgroup.com/?l=linux-xfs&m=99980808004670&w=2 Or the start of the thread: http://marc.theaimsgroup.com/?l=linux-xfs&m=99919025308712&w=2 The reason I am almost convinced it is the same issue is that about every 3 attempts I have only bdflush running and everything else in deadlock. - I will have to follow the instructions and see what output I get from kdb. It appears that although they could only get it to crash with SCSI the problem affects both SCSI & IDE. I was going to short-cut the process and just download the cvs tree - but for some reason the XFS site times-out at the moment. I will try later. When your machine hangs - have you noticed any trends in what processes are left running? Adrian Head P/L > -----Original Message----- > From: Simon Matter [SMTP:simon.matter@ch.sauter-bc.com] > Sent: Tuesday, 11 September 2001 00:28 > To: Adrian Head > Cc: linux-xfs@oss.sgi.com > Subject: Re: Problems with many processes copying large > directories acrossan XFS volume. > > > I tried 20, 40 and 80 simultanous cp with no crash. Then I changed the > file tree and the new tree has ~280M small files with 100b-50kb size. > When using 60 cp jobs the machine died. I could ping it but nothing > more. No ssh, no console, no shutdown. I try some more tests tonight. > I > try the same with ext2 as well to make sure it's XFS and not Softraid. > > -Simon > > From owner-linux-xfs@oss.sgi.com Mon Sep 10 18:31:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B1VTR01898 for linux-xfs-outgoing; Mon, 10 Sep 2001 18:31:29 -0700 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B1VPd01872 for ; Mon, 10 Sep 2001 18:31:25 -0700 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8B1VKJ03578 for ; Mon, 10 Sep 2001 18:31:20 -0700 Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA61495 for ; Mon, 10 Sep 2001 18:36:35 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 416A915A213 for ; Mon, 10 Sep 2001 18:30:04 -0700 (PDT) Subject: 1.0.1 doesn't work with SGI1100 From: Florin Andrei To: linux-xfs Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 10 Sep 2001 18:30:04 -0700 Message-Id: <1000171804.24471.129.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Guys, Looks like XFS-1.0.1 (the installer from the CD-ROM image) doesn't work with SGI 1100 systems (1x or 2xPIII/800, 1x or 2x18GB IDE). I saw the problem on systems with either one or two IDE drives. It doesn't matter if i install from the CD-ROM or through the network, the result is the same. The installer boots just fine, it does all kind of things, the partitioning is fine, but then, when it tries to mount the newly created filesystems, its solid frozen; nothing works. If i switch to ALT-F4 before it's frozen, i see this: [...] <4>Start mounting filesystem: ide0(3,6) <4>Ending clean XFS mount for filesystem: ide0(3,6) <4>Start mounting filesystem: ide0(3,65) <4>hdb: timeout waiting for DMA <4>ide_dmaproc: chipset supported ide_dma_timeout func only: 14 After the last message, it's dead. :-/ I tried different kernel parameters, like "apic", but nothing helps. It looks like the problem occurs no matter how i partition the disk, as long as i have a large partition. I can reproduce the problem any time you want. I never managed to install XFS-1.0.1 on a SGI 1100 system. The problem doesn't seem to occur with XFS-1.0 Is there any solution for this? (installing 1.0 and upgrading to 1.0.1 is not an option, since i have to create an automatic procedure to install 1.0.1 very fast on many SGI1100s - a kickstart disk - and "install and upgrade" kind of defeats the very idea of kickstart) -- Florin Andrei "Our kernel does have source control: its name is Linus Torvalds, CVS with a brain." - Nicholas Knight From owner-linux-xfs@oss.sgi.com Mon Sep 10 18:34:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B1YPk02040 for linux-xfs-outgoing; Mon, 10 Sep 2001 18:34:25 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B1Y3d02018; Mon, 10 Sep 2001 18:34:04 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8B1Y4d02019 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 18:55:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B1tCC02658 for linux-xfs-outgoing; Mon, 10 Sep 2001 18:55:12 -0700 Received: from mail.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B1tAd02639 for ; Mon, 10 Sep 2001 18:55:10 -0700 Message-Id: <200109110155.f8B1tAd02639@oss.sgi.com> Received: (qmail 2367 invoked from network); 11 Sep 2001 01:55:10 -0000 Received: from unknown (HELO there) ([216.254.50.68]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 11 Sep 2001 01:55:10 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Steven Farrier To: linux-xfs@oss.sgi.com Subject: Shrinking XFS partitions Date: Mon, 10 Sep 2001 18:53:52 -0700 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I know it is possible to make XFS partitions bigger, but will it ever be possible to shrink them? Steve From owner-linux-xfs@oss.sgi.com Mon Sep 10 18:55:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B1tdp02787 for linux-xfs-outgoing; Mon, 10 Sep 2001 18:55:39 -0700 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B1tbd02768 for ; Mon, 10 Sep 2001 18:55:37 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8B1tWJ06419 for ; Mon, 10 Sep 2001 18:55:32 -0700 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id f8B1sV540906650; Mon, 10 Sep 2001 18:54:31 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id F13FB300095; Tue, 11 Sep 2001 11:53:40 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id BBF41AB; Tue, 11 Sep 2001 11:53:40 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Florin Andrei Cc: linux-xfs Subject: Re: 1.0.1 doesn't work with SGI1100 In-reply-to: Your message of "10 Sep 2001 18:30:04 MST." <1000171804.24471.129.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Sep 2001 11:53:35 +1000 Message-ID: <27500.1000173215@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10 Sep 2001 18:30:04 -0700, Florin Andrei wrote: >Looks like XFS-1.0.1 (the installer from the CD-ROM image) doesn't work >with SGI 1100 systems (1x or 2xPIII/800, 1x or 2x18GB IDE). ><4>Start mounting filesystem: ide0(3,6) ><4>Ending clean XFS mount for filesystem: ide0(3,6) ><4>Start mounting filesystem: ide0(3,65) ><4>hdb: timeout waiting for DMA ><4>ide_dmaproc: chipset supported ide_dma_timeout func only: 14 Does booting with "ide=nodma" help? From owner-linux-xfs@oss.sgi.com Mon Sep 10 18:56:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B1ue002962 for linux-xfs-outgoing; Mon, 10 Sep 2001 18:56:40 -0700 Received: from main.braxis.co.uk (root@main.braxis.co.uk [213.77.40.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B1uQd02926 for ; Mon, 10 Sep 2001 18:56:26 -0700 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.11.6/8.11.6) id f8B1uRN02123 for linux-xfs@oss.sgi.com; Tue, 11 Sep 2001 03:56:27 +0200 Date: Tue, 11 Sep 2001 03:56:27 +0200 From: Krzysztof Rusocki To: linux-xfs@oss.sgi.com Subject: linux-2.4.10-pre7-xfs-2001-09-10.patch.bz2 cuts a large number of mips files Message-ID: <20010911035627.A1921@main.braxis.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi everybody, I've just noticed that -rw-r--r-- 1 10190 10010 949171 Sep 10 09:08 linux-2.4.10-pre7-xfs-2001-09-10.patch.bz2 obtained by ftp from oss.sgi.com/projects/xfs/download/patches/ erases _a_lot_ of mips related files CVS tree has all of them... so apparently patch-maker had incomplete tree :/ Who's looking after patches/ subdir on oss.sgi.com ? just wondering.... Cheers, Krzysztof From owner-linux-xfs@oss.sgi.com Mon Sep 10 19:07:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B27ve03515 for linux-xfs-outgoing; Mon, 10 Sep 2001 19:07:57 -0700 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B27sd03496 for ; Mon, 10 Sep 2001 19:07:54 -0700 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8B27nJ06623 for ; Mon, 10 Sep 2001 19:07:49 -0700 Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA82974 for ; Mon, 10 Sep 2001 19:13:04 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 4DD3515A213 for ; Mon, 10 Sep 2001 19:06:32 -0700 (PDT) Subject: Re: 1.0.1 doesn't work with SGI1100 From: Florin Andrei To: linux-xfs In-Reply-To: <27500.1000173215@kao2.melbourne.sgi.com> References: <27500.1000173215@kao2.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 10 Sep 2001 19:06:32 -0700 Message-Id: <1000173992.24442.141.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 11 Sep 2001 11:53:35 +1000, Keith Owens wrote: > On 10 Sep 2001 18:30:04 -0700, > Florin Andrei wrote: > >Looks like XFS-1.0.1 (the installer from the CD-ROM image) doesn't work > >with SGI 1100 systems (1x or 2xPIII/800, 1x or 2x18GB IDE). > ><4>Start mounting filesystem: ide0(3,6) > ><4>Ending clean XFS mount for filesystem: ide0(3,6) > ><4>Start mounting filesystem: ide0(3,65) > ><4>hdb: timeout waiting for DMA > ><4>ide_dmaproc: chipset supported ide_dma_timeout func only: 14 > > Does booting with "ide=nodma" help? Ah, right. That solves the problem. Thanks a lot. But why it doesn't work without it anyway? -- Florin Andrei "Our kernel does have source control: its name is Linus Torvalds, CVS with a brain." - Nicholas Knight From owner-linux-xfs@oss.sgi.com Mon Sep 10 19:25:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B2PfE03865 for linux-xfs-outgoing; Mon, 10 Sep 2001 19:25:41 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B2Pbd03846 for ; Mon, 10 Sep 2001 19:25:37 -0700 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA05749 for ; Mon, 10 Sep 2001 19:24:07 -0700 (PDT) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA04091 for ; Mon, 10 Sep 2001 19:30:46 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 876A415A213 for ; Mon, 10 Sep 2001 19:24:15 -0700 (PDT) Subject: Re: 1.0.1 doesn't work with SGI1100 From: Florin Andrei To: linux-xfs In-Reply-To: <1000173992.24442.141.camel@stantz.corp.sgi.com> References: <27500.1000173215@kao2.melbourne.sgi.com> <1000173992.24442.141.camel@stantz.corp.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 10 Sep 2001 19:24:15 -0700 Message-Id: <1000175055.23809.155.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10 Sep 2001 19:06:32 -0700, Florin Andrei wrote: > On 11 Sep 2001 11:53:35 +1000, Keith Owens wrote: > > > > Does booting with "ide=nodma" help? > > Ah, right. That solves the problem. Thanks a lot. A quick follow-up: ide=nodma solves the problem for the installer. But, after the install, when the system comes up for the first time, it's the same problem: it's frozen when it tries to mount large partitions. I can add to the kickstart file, to the lilo option, the "--append ide=nodma" string, and it appears to solve the problem. But, still, if i want a high performance from that system (and believe me, i do want that, since it's gonna be a busy mail gateway), not using DMA will hurt performance. Somehow, i believe this problem is specific to the kernel version from 1.0.1, since 1.0 doesn't exhibit the same problem. I'm not sure of that, but i believe the vanilla Red Hat 7.1 doesn't show this problem. So, maybe a kernel upgrade will make it dissapear? I'll try and see what i can do. -- Florin Andrei "Our kernel does have source control: its name is Linus Torvalds, CVS with a brain." - Nicholas Knight From owner-linux-xfs@oss.sgi.com Mon Sep 10 19:35:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B2Zv604106 for linux-xfs-outgoing; Mon, 10 Sep 2001 19:35:57 -0700 Received: from hotmail.com (f113.law7.hotmail.com [216.33.237.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B2Ztd04086 for ; Mon, 10 Sep 2001 19:35:55 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 10 Sep 2001 19:35:48 -0700 Received: from 211.99.247.66 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 11 Sep 2001 02:35:47 GMT X-Originating-IP: [211.99.247.66] From: "Harrison Xing" To: linux-xfs@oss.sgi.com Subject: Memory leak in XFS 1.0.1 ? Just mount and umount Date: Tue, 11 Sep 2001 10:35:47 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Sep 2001 02:35:48.0204 (UTC) FILETIME=[77173AC0:01C13A6A] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, When I mount and umount XFS heavily it seems that there are memory leaks. After about a day, the machine becomes quite slow and there is little free memory left, the buffers and cached memory are almost exhausted. for((i=1;i<10,000,000;i++));do mount -t xfs /dev/hda6 /mnt/xfs umount /mnt/xfs done I use the 2.4.5 kernel with XFS 1.0.1 release. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-linux-xfs@oss.sgi.com Mon Sep 10 19:43:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B2h4304284 for linux-xfs-outgoing; Mon, 10 Sep 2001 19:43:04 -0700 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B2h2d04265 for ; Mon, 10 Sep 2001 19:43:02 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8B2guJ07292 for ; Mon, 10 Sep 2001 19:42:56 -0700 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id f8B2ft541409492; Mon, 10 Sep 2001 19:41:55 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 30465300095; Tue, 11 Sep 2001 12:41:05 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id DA40DAB; Tue, 11 Sep 2001 12:41:05 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Florin Andrei Cc: linux-xfs Subject: Re: 1.0.1 doesn't work with SGI1100 In-reply-to: Your message of "10 Sep 2001 19:24:15 MST." <1000175055.23809.155.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Sep 2001 12:41:00 +1000 Message-ID: <27772.1000176060@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10 Sep 2001 19:24:15 -0700, Florin Andrei wrote: >ide=nodma solves the problem for the installer. But, after the install, >when the system comes up for the first time, it's the same problem: it's >frozen when it tries to mount large partitions. >I can add to the kickstart file, to the lilo option, the "--append >ide=nodma" string, and it appears to solve the problem. But, still, if i >want a high performance from that system (and believe me, i do want >that, since it's gonna be a busy mail gateway), not using DMA will hurt >performance. It is likely to be a chipset problem rather than XFS. RH 7.1 was probably compiled without CONFIG_IDEDMA_PCI_AUTO. From owner-linux-xfs@oss.sgi.com Mon Sep 10 20:04:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B34Ha04636 for linux-xfs-outgoing; Mon, 10 Sep 2001 20:04:17 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B33ud04615; Mon, 10 Sep 2001 20:03:56 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8B33vd04616 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 20:22:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B3MOv04940 for linux-xfs-outgoing; Mon, 10 Sep 2001 20:22:24 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B3M9d04918 for ; Mon, 10 Sep 2001 20:22:09 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA00862 for ; Mon, 10 Sep 2001 20:21:50 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id NAA19611; Tue, 11 Sep 2001 13:21:24 +1000 Date: Tue, 11 Sep 2001 13:21:24 +1000 From: Keith Owens Message-Id: <200109110321.NAA19611@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade to 2.4.10-pre8 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Upgrade to 2.4.10-pre8. Linus has reverted the min/max changes, the functions take two parameters again. However the kernel min/max definitions now warn if the types are different. This take changes MIN/MAX in xfs_linux.h to use the kernel min/max and it highlighted some problems. xfs_ag.h is messy, the macro definitions use the variable types which are typically uint or uint8, returning uint but the equivalent functions are defined with int parameters, returning int. The following warnings need to be fixed by somebody who knows the code better than I. xfs_alloc.c: In function `xfs_alloc_fix_freelist': xfs_alloc.c:1810: warning: comparison of distinct pointer types lacks a cast xfs_alloc.c:1810: warning: comparison of distinct pointer types lacks a cast xfs_bmap.c: In function `xfs_bmap_alloc': xfs_bmap.c:2529: warning: comparison of distinct pointer types lacks a cast xfs_bmap.c:2529: warning: comparison of distinct pointer types lacks a cast xfs_bmap.c: In function `xfs_getbmap': xfs_bmap.c:5600: warning: comparison of distinct pointer types lacks a cast xfs_bmap.c:5715: warning: comparison of distinct pointer types lacks a cast xfs_dir2_leaf.c: In function `xfs_dir2_leaf_getdents': xfs_dir2_leaf.c:841: warning: comparison of distinct pointer types lacks a cast xfs_dir2_leaf.c:994: warning: comparison of distinct pointer types lacks a cast xfs_log_recover.c: In function `xlog_recover_do_buffer_trans': xfs_log_recover.c:1937: warning: comparison of distinct pointer types lacks a cast xfs_mount.c: In function `xfs_mount_common': xfs_mount.c:467: warning: comparison of distinct pointer types lacks a cast xfs_trans.c: In function `xfs_trans_init': xfs_trans.c:74: warning: comparison of distinct pointer types lacks a cast xfs_vnodeops.c: In function `xfs_set_uiosize': xfs_vnodeops.c:4941: warning: comparison of distinct pointer types lacks a cast xfs_vnodeops.c:4952: warning: comparison of distinct pointer types lacks a cast xfs_vnodeops.c:4958: warning: comparison of distinct pointer types lacks a cast xfs_vnodeops.c: In function `xfs_free_file_space': xfs_vnodeops.c:5596: warning: comparison of distinct pointer types lacks a cast Date: Mon Sep 10 20:12:20 PDT 2001 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102561a linux/net/x25/af_x25.c - 1.22 linux/net/wanrouter/wanproc.c - 1.18 linux/net/unix/af_unix.c - 1.34 linux/net/sunrpc/xprt.c - 1.18 linux/net/sched/sch_tbf.c - 1.9 linux/net/rose/af_rose.c - 1.20 linux/net/netrom/af_netrom.c - 1.20 linux/net/irda/af_irda.c - 1.24 linux/net/ipx/af_ipx.c - 1.22 linux/net/ipv6/route.c - 1.19 linux/net/ipv6/raw.c - 1.20 linux/net/ipv6/ndisc.c - 1.15 linux/net/ipv6/ipv6_sockglue.c - 1.12 linux/net/ipv6/icmp.c - 1.15 linux/net/ipv4/tcp_timer.c - 1.20 linux/net/ipv4/tcp_output.c - 1.21 linux/net/ipv4/tcp_input.c - 1.28 linux/net/ipv4/tcp.c - 1.30 linux/net/ipv4/route.c - 1.25 linux/net/ipv4/ipmr.c - 1.18 linux/net/ipv4/ip_sockglue.c - 1.15 linux/net/core/iovec.c - 1.9 linux/net/ax25/af_ax25.c - 1.21 linux/net/appletalk/ddp.c - 1.19 linux/mm/slab.c - 1.26 linux/mm/memory.c - 1.58 linux/kernel/ksyms.c - 1.106 linux/kernel/fork.c - 1.35 linux/kernel/exit.c - 1.30 linux/kernel/exec_domain.c - 1.12 linux/kernel/Makefile - 1.24 linux/include/net/tcp.h - 1.24 linux/include/net/sock.h - 1.24 linux/include/linux/sysctl.h - 1.35 linux/include/linux/swap.h - 1.37 linux/include/linux/sched.h - 1.43 linux/include/linux/personality.h - 1.9 linux/include/linux/mm.h - 1.61 linux/include/linux/kernel.h - 1.24 linux/include/linux/fs.h - 1.116 linux/include/asm-i386/uaccess.h - 1.12 linux/include/asm-i386/spinlock.h - 1.20 linux/include/asm-i386/processor.h - 1.26 linux/include/asm-i386/io.h - 1.17 linux/fs/umsdos/inode.c - 1.18 linux/fs/ufs/util.h - 1.6 linux/fs/ufs/util.c - 1.7 linux/fs/ufs/truncate.c - 1.10 linux/fs/ufs/balloc.c - 1.7 linux/fs/sysv/inode.c - 1.24 linux/fs/smbfs/inode.c - 1.23 linux/fs/select.c - 1.18 linux/fs/romfs/inode.c - 1.24 linux/fs/ncpfs/ncpsign_kernel.c - 1.4 linux/fs/ncpfs/ncplib_kernel.c - 1.10 linux/fs/ncpfs/mmap.c - 1.15 linux/fs/ncpfs/ioctl.c - 1.15 linux/fs/ncpfs/inode.c - 1.21 linux/fs/ncpfs/file.c - 1.17 linux/fs/namei.c - 1.36 linux/fs/isofs/rock.c - 1.14 linux/fs/hfs/inode.c - 1.13 linux/fs/hfs/file_cap.c - 1.10 linux/fs/coda/upcall.c - 1.13 linux/fs/buffer.c - 1.81 linux/fs/attr.c - 1.10 linux/fs/adfs/inode.c - 1.17 linux/drivers/usb/uhci.c - 1.47 linux/drivers/scsi/sym53c8xx.h - 1.7 linux/drivers/scsi/sr_ioctl.c - 1.18 linux/drivers/scsi/sd.c - 1.44 linux/drivers/scsi/eata_pio.c - 1.13 linux/drivers/net/hamradio/baycom_epp.c - 1.17 linux/drivers/net/dgrs.c - 1.19 linux/drivers/net/de600.c - 1.15 linux/drivers/net/acenic.c - 1.30 linux/drivers/char/dsp56k.c - 1.17 linux/drivers/char/cyclades.c - 1.19 linux/drivers/block/xd.c - 1.22 linux/drivers/block/rd.c - 1.33 linux/drivers/block/ps2esdi.c - 1.21 linux/drivers/block/paride/pf.c - 1.13 linux/drivers/block/paride/pd.c - 1.17 linux/drivers/block/nbd.c - 1.21 linux/drivers/block/loop.c - 1.35 linux/drivers/block/floppy.c - 1.27 linux/drivers/block/amiflop.c - 1.15 linux/drivers/block/acsi.c - 1.16 linux/drivers/acorn/scsi/acornscsi.c - 1.9 linux/drivers/acorn/block/mfmhd.c - 1.13 linux/arch/sparc64/solaris/timod.c - 1.14 linux/arch/sparc64/solaris/misc.c - 1.19 linux/arch/i386/lib/Makefile - 1.16 linux/arch/i386/kernel/signal.c - 1.18 linux/arch/i386/kernel/i386_ksyms.c - 1.40 linux/arch/arm/kernel/traps.c - 1.21 linux/Makefile - 1.121 linux/Documentation/sysctl/vm.txt - 1.6 linux/fs/hpfs/inode.c - 1.14 linux/drivers/i2o/i2o_block.c - 1.29 linux/drivers/block/blkpg.c - 1.11 linux/arch/arm/kernel/arthur.c - 1.8 linux/drivers/char/ppdev.c - 1.24 linux/drivers/block/cpqarray.c - 1.27 linux/net/khttpd/waitheaders.c - 1.6 linux/net/khttpd/rfc.c - 1.6 linux/net/khttpd/datasending.c - 1.9 linux/drivers/block/DAC960.c - 1.36 linux/drivers/net/wan/cycx_main.c - 1.12 linux/drivers/net/wan/sdla_x25.c - 1.11 linux/drivers/net/wan/sdla_ppp.c - 1.14 linux/drivers/net/wan/sdla_fr.c - 1.15 linux/drivers/net/wan/sbni.c - 1.15 linux/drivers/net/wan/cycx_x25.c - 1.14 linux/drivers/char/agp/agpgart_be.c - 1.22 linux/drivers/sbus/char/jsflash.c - 1.9 linux/drivers/usb/devio.c - 1.18 linux/drivers/net/wan/sdla_chdlc.c - 1.13 linux/drivers/usb/usb-uhci.c - 1.27 linux/drivers/usb/usb-ohci.c - 1.26 linux/include/linux/ac97_codec.h - 1.11 linux/drivers/ide/ide.c - 1.29 linux/drivers/ide/hd.c - 1.12 linux/drivers/net/wan/comx.c - 1.12 linux/drivers/net/wan/comx-proto-lapb.c - 1.7 linux/drivers/net/wan/comx-proto-fr.c - 1.7 linux/drivers/net/wan/comx-hw-mixcom.c - 1.7 linux/drivers/net/wan/comx-hw-locomx.c - 1.5 linux/drivers/net/wan/comx-hw-comx.c - 1.6 linux/net/ipv4/netfilter/ipfwadm_core.c - 1.7 linux/net/ipv4/netfilter/ipchains_core.c - 1.6 linux/drivers/sound/dmasound/dmasound_q40.c - 1.5 linux/drivers/sound/dmasound/dmasound_paula.c - 1.5 linux/drivers/sound/dmasound/dmasound_awacs.c - 1.8 linux/drivers/sound/dmasound/dmasound_atari.c - 1.6 linux/drivers/usb/serial/usbserial.c - 1.20 linux/drivers/usb/serial/visor.c - 1.21 linux/drivers/sound/emu10k1/cardwo.c - 1.6 linux/drivers/sound/emu10k1/cardwi.c - 1.5 linux/drivers/sound/emu10k1/audio.c - 1.12 linux/drivers/usb/serial/digi_acceleport.c - 1.15 linux/drivers/char/rio/riointr.c - 1.5 linux/drivers/s390/net/iucv.c - 1.6 linux/drivers/s390/block/dasd.c - 1.12 linux/fs/xfs/xfs_dir2_trace.c - 1.10 linux/fs/xfs/linux/xfs_lrw.c - 1.108 linux/fs/xfs/linux/xfs_linux.h - 1.54 linux/fs/pagebuf/page_buf_io.c - 1.96 linux/drivers/usb/bluetooth.c - 1.15 linux/fs/jffs/inode-v23.c - 1.11 linux/fs/jffs/intrep.c - 1.7 linux/drivers/mtd/ftl.c - 1.7 linux/drivers/mtd/mtdblock.c - 1.6 linux/net/ipv4/tcp_minisocks.c - 1.8 linux/drivers/md/lvm.c - 1.19 linux/drivers/block/cciss.c - 1.14 linux/drivers/md/lvm-snap.c - 1.6 linux/drivers/md/md.c - 1.22 linux/drivers/usb/serial/empeg.c - 1.11 linux/drivers/s390/net/netiucv.c - 1.6 linux/drivers/s390/block/xpram.c - 1.5 linux/fs/xfs_support/qsort.c - 1.3 linux/drivers/usb/serial/io_usbvend.h - 1.3 linux/drivers/usb/serial/io_edgeport.c - 1.8 linux/drivers/net/wan/wanpipe_multppp.c - 1.6 linux/arch/cris/drivers/usb-host.c - 1.6 linux/drivers/mtd/nftlcore.c - 1.4 linux/drivers/mtd/mtdblock_ro.c - 1.2 linux/drivers/mtd/devices/docecc.c - 1.3 linux/drivers/net/wireless/airo.c - 1.5 linux/drivers/net/sk98lin/skproc.c - 1.7 linux/drivers/usb/storage/jumpshot.c - 1.3 linux/drivers/usb/storage/datafab.c - 1.3 From owner-linux-xfs@oss.sgi.com Mon Sep 10 21:27:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B4RSu06267 for linux-xfs-outgoing; Mon, 10 Sep 2001 21:27:28 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B4RFd06244; Mon, 10 Sep 2001 21:27:16 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8B4RGd06249 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 22:46:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B5kRs07681 for linux-xfs-outgoing; Mon, 10 Sep 2001 22:46:27 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B5kEd07657 for ; Mon, 10 Sep 2001 22:46:14 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id HAA08696; Tue, 11 Sep 2001 07:45:47 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id HAA18259; Tue, 11 Sep 2001 07:44:21 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id EF65757306; Tue, 11 Sep 2001 07:43:47 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id E3E7B25835; Tue, 11 Sep 2001 07:43:47 +0200 (CEST) Message-ID: <3B9DA493.11CD4C16@ch.sauter-bc.com> Date: Tue, 11 Sep 2001 07:43:47 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Adrian Head , linux-xfs@oss.sgi.com Subject: Re: Problems with many processes copying large directories acrossan XFS volume. References: <3B9CCE00.D704DC0B@ch.sauter-bc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter schrieb: > > Adrian Head schrieb: > > > > Thanks for your reply Simon > > > > Yes the softraid was fully synced before I started any test. > > > > The XFS patch I used to obtain these errors was > > patch-2.4.9-xfs-2001-08-19 and the errors were: > > Sep 9 05:13:46 ATLAS kernel: 02:86: rw=0, want=156092516, limit=360 > > Sep 9 05:13:46 ATLAS kernel: attempt to access beyond end of device > > > > When I used a later version of the XFS patch I had more descriptive > > errors written to /var/log/messages: > > Sep 10 10:14:57 ATLAS kernel: I/O error in filesystem ("md(9,0)") > > meta-data dev 0x900 block 0x9802bdc > > Sep 10 10:14:57 ATLAS kernel: (xlog_iodone") error 5 buf count 32768 > > Sep 10 10:14:57 ATLAS kernel: xfs_force_shutdown(md(9,0),0x2) called > > from line 940 of file xfs_log.c. Return address - 0xd8cb66f8 > > Sep 10 10:14:57 ATLAS kernel: Log I/O Error Detected. Shutting down > > filesystem: md(9,0) > > Sep 10 10:14:57 ATLAS kernel: Please umount the filesystem, and rectify > > the problem(s) > > Sep 10 10:14:57 ATLAS kernel: xfs_force_shutdown(md(9,0),0x2) called > > from line 714 of file xfs_log.c. Return address = 0xd8cb65d3 > > Sep 10 10:14:57 ATLAS kernel: attempt to access beyond end of device > > Sep 10 10:14:57 ATLAS kernel: 02:82: rw=0, want=1602235696, limit=4 > > > > I did think at the time that it may have been issues with XFS stomping > > all over raid code or raid code stomping all over XFS. Although I not > > sure now as the 2.4.10-pre2-xfs-2001-09-02 patch never wrote any errors > > out at all. (please see my 2nd post for more info) > > > > Thanks for taking the time to test this on your own machine. > > I tried 20, 40 and 80 simultanous cp with no crash. Then I changed the > file tree and the new tree has ~280M small files with 100b-50kb size. > When using 60 cp jobs the machine died. I could ping it but nothing > more. No ssh, no console, no shutdown. I try some more tests tonight. I > try the same with ext2 as well to make sure it's XFS and not Softraid. Update: I tried the 60 cp jobs on a ext2 filesystem and the system is still alive but 58 of the 60 cp jobs are hanging. Well maybe the 2.4.3 kernel is a bit old now... I'll try some more tests. Simon > > -Simon > > > > > Adrian Head > > Bytecomm P/L > > > > > -----Original Message----- > > > From: Simon Matter [SMTP:simon.matter@ch.sauter-bc.com] > > > Sent: Monday, 10 September 2001 17:45 > > > To: adrian.head@bytecomm.com.au > > > Cc: linux-xfs@oss.sgi.com > > > Subject: Re: Problems with many processes copying large > > > directories across an XFS volume. > > > > > > Hi Adrian > > > > > > I did similar tests two months ago. I was having problems as well but > > > ufurtunately I don't remember what is was exactly. > > > First question: You created Softraid5, was the raid synced when you > > > started the tests? > > > > > > > In the /var/log/messages log around the same time as the copy test I > > > get > > > > entries like: > > > > Sep 9 05:13:46 ATLAS kernel: 02:86: rw=0, want=156092516, limit=360 > > > > Sep 9 05:13:46 ATLAS kernel: attempt to access beyond end of device > > > > > > This looks interesting. I don't know what this means exactly but it > > > looks to me like you managed to create a filesystem bigger than the > > > raid > > > volume was? I got the very same error when I tried to restore data > > > with > > > xfsrestore from DAT (xfsrestore from DLT was fine). The issue is still > > > open. > > > > > > I have a test system here with SoftRAID5 on 4 U160 SCSI disks. I'll > > > try > > > to kill it today with cp jobs. > > > > > > -Simon > > > From owner-linux-xfs@oss.sgi.com Mon Sep 10 22:50:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B5oh107882 for linux-xfs-outgoing; Mon, 10 Sep 2001 22:50:43 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B5oad07840; Mon, 10 Sep 2001 22:50:36 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8B5obd07841 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Mon Sep 10 22:50:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B5olb07936 for linux-xfs-outgoing; Mon, 10 Sep 2001 22:50:47 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B5ofd07846 for ; Mon, 10 Sep 2001 22:50:41 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id WAA28665 for ; Mon, 10 Sep 2001 22:50:44 -0700 (PDT) mail_from (ivanr@melbourne.sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA08766; Tue, 11 Sep 2001 16:49:20 +1100 From: ivanr@melbourne.sgi.com (Ivan Rayner) Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id PAA24814; Tue, 11 Sep 2001 15:49:19 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Tue, 11 Sep 2001 15:49:18 +1000 To: Russel Ingram cc: Subject: Re: xfsdump error question In-Reply-To: <20010910114627.A1640@roujin.gargoylecc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 10 Sep 2001, Russel Ingram wrote: > xfsdump: calling bulkstat > xfsdump: bulkstat returns buflen 4096 ino 5282011 > xfsdump: ino 5768703 needed second bulkstat > xfsdump: ERROR: map_add(5243008, 3): ino(5243008) <= last_ino(5768702) ... > Can someone tell me what this error means and if its something I'm > doing wrong or if its a problem with my filesystem or xfsdump? > I've also attached the output from running the same command with -v5. When xfsdump does a bulkstat to get the stat information for a whole bunch of files, it can sometimes detect inconsistencies which usually means the inode is or has just been modified. xfsdump will then call bulkstat_single to reget this information. In your case, xfsdump tried to reget the stat information for inode 5768703 but it got back information for inode 5243008. This is a problem. Looking at the code, the bulkstat_single probably would have returned an errno, but xfsdump doesn't check the return value for the ioctl, and it continues to process the stat info, but dies when it realises that it shouldn't have an ino which is out of sequence. So, the question is, is there a problem with your filesystem? Can you do a: # find / -inum 5243008 -o -inum 5768703 to see which files these inode numbers represent? In the xfstests package, there is a program called bstat. It will go through a filesystem comparing what it gets from bulkstat with regular stat information. You should redirect it's output to a file ... there will be alot of it: # bstat -C -l 5243000 > bstat.log When it's done, take a look at the bstat.log to see if there are any inconsistencies with inodes 5243008 and 5768703. It might also be interesting to see the inode information from xfs_db: # xfs_db -r /dev/ xfs_db: inode 5243008 xfs_db: p xfs_db: inode 5768703 xfs_db: p And I suppose you could remount your root filesystem readonly and run xfs_repair and see what it produces. Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Mon Sep 10 23:13:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B6Dnf08612 for linux-xfs-outgoing; Mon, 10 Sep 2001 23:13:49 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B6Dcd08592 for ; Mon, 10 Sep 2001 23:13:38 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA13985; Tue, 11 Sep 2001 08:13:02 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA21193; Tue, 11 Sep 2001 08:12:56 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id D557857306; Tue, 11 Sep 2001 08:11:23 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id C605325835; Tue, 11 Sep 2001 08:11:23 +0200 (CEST) Message-ID: <3B9DAB0B.57915665@ch.sauter-bc.com> Date: Tue, 11 Sep 2001 08:11:23 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Adrian Head Cc: linux-xfs@oss.sgi.com Subject: Re: Problems with many processes copying large directories acrossan XFS volume. References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Adrian Head schrieb: > > Again - thanks Simon for your time. > > I have done ten's of tests now and I am getting a strong feeling that it > is the same problems described here from Steve Lord: > http://marc.theaimsgroup.com/?l=linux-xfs&m=99980808004670&w=2 > > Or the start of the thread: > http://marc.theaimsgroup.com/?l=linux-xfs&m=99919025308712&w=2 > > The reason I am almost convinced it is the same issue is that about > every 3 attempts I have only bdflush running and everything else in > deadlock. - I will have to follow the instructions and see what output I > get from kdb. So do I. > > It appears that although they could only get it to crash with SCSI the > problem affects both SCSI & IDE. > > I was going to short-cut the process and just download the cvs tree - > but for some reason the XFS site times-out at the moment. I will try > later. > > When your machine hangs - have you noticed any trends in what processes > are left running? Unfortunately it disabled kdb and was not able to get a process list. I'm still trying more tests and I will also try a current kernel if time permits. Simon > > Adrian Head P/L > > > -----Original Message----- > > From: Simon Matter [SMTP:simon.matter@ch.sauter-bc.com] > > Sent: Tuesday, 11 September 2001 00:28 > > To: Adrian Head > > Cc: linux-xfs@oss.sgi.com > > Subject: Re: Problems with many processes copying large > > directories acrossan XFS volume. > > > > > > I tried 20, 40 and 80 simultanous cp with no crash. Then I changed the > > file tree and the new tree has ~280M small files with 100b-50kb size. > > When using 60 cp jobs the machine died. I could ping it but nothing > > more. No ssh, no console, no shutdown. I try some more tests tonight. > > I > > try the same with ext2 as well to make sure it's XFS and not Softraid. > > > > -Simon > > > > From owner-linux-xfs@oss.sgi.com Tue Sep 11 00:20:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B7Kd410031 for linux-xfs-outgoing; Tue, 11 Sep 2001 00:20:39 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B7KYd10012; Tue, 11 Sep 2001 00:20:34 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8B7KZd10013 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Tue Sep 11 01:44:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8B8iYW11569 for linux-xfs-outgoing; Tue, 11 Sep 2001 01:44:34 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8B8hsd11543; Tue, 11 Sep 2001 01:43:54 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8B8hsd11544 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Tue Sep 11 03:07:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BA7JM13170 for linux-xfs-outgoing; Tue, 11 Sep 2001 03:07:19 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BA7Dd13151; Tue, 11 Sep 2001 03:07:14 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8BA7Ed13152 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Tue Sep 11 04:26:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BBQ6714520 for linux-xfs-outgoing; Tue, 11 Sep 2001 04:26:06 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BBQ1d14501; Tue, 11 Sep 2001 04:26:01 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8BBQ2d14502 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Tue Sep 11 05:04:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BC4u815171 for linux-xfs-outgoing; Tue, 11 Sep 2001 05:04:56 -0700 Received: from hammail1.truenorth.com (h-213.61.138.102.host.de.colt.net [213.61.138.102]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BC4qd15152 for ; Tue, 11 Sep 2001 05:04:52 -0700 Received: from fcb-wilkens.com ([170.200.66.15]) by hammail1.truenorth.com (Netscape Messaging Server 4.15) with ESMTP id GJHYVW00.S95; Tue, 11 Sep 2001 14:04:44 +0200 Message-ID: <3B9DFDDC.C0480DA3@fcb-wilkens.com> Date: Tue, 11 Sep 2001 14:04:44 +0200 From: Harald Wagener Organization: FCB Wilkens X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: stimits@idcomm.com CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: ".", "..", and cd References: <3B99B55E.CF8F4F16@idcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "D. Stimits" wrote: > > This is probably not an XFS question per se, but might be, I'm not sure. > I use XFS on the root system, and am working on some directory and file > scanning code. One of the banes of this is to scan for files or > directories beginning with ".", without always viewing the current > directory and its parent directory, "..". While doing some testing of > special cases, I discovered that if I look for files in the root > directory "/" (on XFS), through the "glob" function (which presumably is > used in code of some shells for its pattern matching), looking for files > of pattern ".*", then doing so in "/" results in both "/./" (I have the > flag set to append "/" to the end of directory values) and "/../". This > latter entry is a curiosity, seeing as the root partition does not have > a parent. If I cd to "/", and then do "cd ..", there is no error either, > I just end up where I started. If You want to omit this, try to match .??* . > Is this the standard, expected behavior (possibly POSIX or HFS > designated)? Or would different filesystems behave differently, where > some complain about "cd .." when already in the root? At this point it > is really nothing more than a curiosity, but it sticks out during > testing. It is the expected behavior. Regards, Harald -- Harald Wagener | Systemadministrator FCB/Wilkens GmbH | Tel.:+49-40-2881-1252 An der Alster 42 | Fax.:+49-40-2881-1263 20099 Hamburg | http://www.fcb-wilkens.com From owner-linux-xfs@oss.sgi.com Tue Sep 11 05:48:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BCmvo15851 for linux-xfs-outgoing; Tue, 11 Sep 2001 05:48:57 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BCmpd15832; Tue, 11 Sep 2001 05:48:52 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8BCmqd15833 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Tue Sep 11 07:12:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BECKk17579 for linux-xfs-outgoing; Tue, 11 Sep 2001 07:12:20 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BEC9d17557; Tue, 11 Sep 2001 07:12:09 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8BECAd17558 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Tue Sep 11 07:37:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BEb7817942 for linux-xfs-outgoing; Tue, 11 Sep 2001 07:37:07 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BEb5d17923 for ; Tue, 11 Sep 2001 07:37:05 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8BEax513190 for ; Tue, 11 Sep 2001 07:36:59 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2944298; Tue, 11 Sep 2001 09:35:44 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA60505; Tue, 11 Sep 2001 09:35:43 -0500 (CDT) Message-ID: <3B9E211B.43CC31B0@sgi.com> Date: Tue, 11 Sep 2001 09:35:07 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Steven Farrier CC: linux-xfs@oss.sgi.com Subject: Re: Shrinking XFS partitions References: <200109110155.f8B1tAd02639@oss.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steven Farrier wrote: > > I know it is possible to make XFS partitions bigger, but will it ever be > possible to shrink them? Short answer is no, for a longer answer, there is a thread in the archives somewhere. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 11 07:38:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BEcfq18074 for linux-xfs-outgoing; Tue, 11 Sep 2001 07:38:41 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BEcdd18055 for ; Tue, 11 Sep 2001 07:38:39 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8BEcY513398 for ; Tue, 11 Sep 2001 07:38:34 -0700 Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2944594; Tue, 11 Sep 2001 09:37:18 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA55558; Tue, 11 Sep 2001 09:37:18 -0500 (CDT) Message-ID: <3B9E2179.B797CDED@sgi.com> Date: Tue, 11 Sep 2001 09:36:41 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Krzysztof Rusocki CC: linux-xfs@oss.sgi.com Subject: Re: linux-2.4.10-pre7-xfs-2001-09-10.patch.bz2 cuts a large number of mips files References: <20010911035627.A1921@main.braxis.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Krzysztof Rusocki wrote: > Who's looking after patches/ subdir on oss.sgi.com ? just wondering.... I am; I'll take a look. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 11 08:38:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BFcJm19113 for linux-xfs-outgoing; Tue, 11 Sep 2001 08:38:19 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BFbHd19057; Tue, 11 Sep 2001 08:37:17 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8BFbId19065 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Tue Sep 11 09:25:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BGP1S19767 for linux-xfs-outgoing; Tue, 11 Sep 2001 09:25:01 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BGOsd19746 for ; Tue, 11 Sep 2001 09:24:54 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8BGOm523342 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Tue, 11 Sep 2001 09:24:48 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id SAA316765 for ; Tue, 11 Sep 2001 18:24:58 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA2945380; Tue, 11 Sep 2001 11:23:30 -0500 (CDT) Received: from sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA45709; Tue, 11 Sep 2001 11:23:29 -0500 (CDT) Message-ID: <3B9E3A5B.8B011E71@sgi.com> Date: Tue, 11 Sep 2001 11:22:51 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Krzysztof Rusocki , linux-xfs@oss.sgi.com Subject: Re: linux-2.4.10-pre7-xfs-2001-09-10.patch.bz2 cuts a large number of mips files References: <20010911035627.A1921@main.braxis.co.uk> <3B9E2179.B797CDED@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > > Krzysztof Rusocki wrote: > > > Who's looking after patches/ subdir on oss.sgi.com ? just wondering.... Ok, the latest patch out there should be OK, I forgot the "-d" on the cvs update script, so new directories were getting lost. Sorry about that, and thanks for the heads up. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 11 09:29:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BGTud19906 for linux-xfs-outgoing; Tue, 11 Sep 2001 09:29:56 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BGTrd19887 for ; Tue, 11 Sep 2001 09:29:53 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f8BGTlw14600 for linux-xfs@oss.sgi.com; Tue, 11 Sep 2001 12:29:47 -0400 Date: Tue, 11 Sep 2001 12:29:47 -0400 From: Alan Eldridge To: SGI XFS Dev List Subject: big failure on a scsi driver Message-ID: <20010911122947.A14588@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Time: 2001-09-11 09:04:03 Command: rpm -ba --target i386,i686 kernel-2.4.spec Building target platforms: i386,i686 Building for target i386 [elided] + make -s -j 1 CC=kgcc modules [elided] cpqfcTSinit.c: In function `cpqfcTS_ioctl': cpqfcTSinit.c:662: `SCSI_IOCTL_FC_TARGET_ADDRESS' undeclared (first use in this function) cpqfcTSinit.c:662: (Each undeclared identifier is reported only once cpqfcTSinit.c:662: for each function it appears in.) cpqfcTSinit.c:680: `SCSI_IOCTL_FC_TDR' undeclared (first use in this function) make[2]: *** [cpqfcTSinit.o] Error 1 make[1]: *** [_modsubdir_scsi] Error 2 make: *** [_mod_drivers] Error 2 error: Bad exit status from /home/alane/rpm/tmp/rpm-tmp.52739 (%build) RPM build errors: Bad exit status from /home/alane/rpm/tmp/rpm-tmp.52739 (%build) 1 -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Tue Sep 11 10:00:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BH0hl20488 for linux-xfs-outgoing; Tue, 11 Sep 2001 10:00:43 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BH0ad20469; Tue, 11 Sep 2001 10:00:36 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8BH0bd20470 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Tue Sep 11 10:34:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BHYBv21020 for linux-xfs-outgoing; Tue, 11 Sep 2001 10:34:11 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BHY7d21001 for ; Tue, 11 Sep 2001 10:34:07 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8BHY2528381 for ; Tue, 11 Sep 2001 10:34:02 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2944169; Tue, 11 Sep 2001 12:32:46 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA34158; Tue, 11 Sep 2001 12:32:46 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f8BHTTR03002; Tue, 11 Sep 2001 12:29:29 -0500 Message-Id: <200109111729.f8BHTTR03002@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Alan Eldridge cc: SGI XFS Dev List Subject: Re: big failure on a scsi driver In-Reply-To: Message from Alan Eldridge of "Tue, 11 Sep 2001 12:29:47 EDT." <20010911122947.A14588@wwweasel.geeksrus.net> Date: Tue, 11 Sep 2001 12:29:28 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Time: 2001-09-11 09:04:03 > Command: rpm -ba --target i386,i686 kernel-2.4.spec > Building target platforms: i386,i686 > Building for target i386 > [elided] > + make -s -j 1 CC=kgcc modules > [elided] > cpqfcTSinit.c: In function `cpqfcTS_ioctl': > cpqfcTSinit.c:662: `SCSI_IOCTL_FC_TARGET_ADDRESS' undeclared (first use in th > is function) > cpqfcTSinit.c:662: (Each undeclared identifier is reported only once > cpqfcTSinit.c:662: for each function it appears in.) > cpqfcTSinit.c:680: `SCSI_IOCTL_FC_TDR' undeclared (first use in this function > ) > make[2]: *** [cpqfcTSinit.o] Error 1 > make[1]: *** [_modsubdir_scsi] Error 2 > make: *** [_mod_drivers] Error 2 > error: Bad exit status from /home/alane/rpm/tmp/rpm-tmp.52739 (%build) > > > RPM build errors: > Bad exit status from /home/alane/rpm/tmp/rpm-tmp.52739 (%build) > 1 > First check your tree is fully upto date, then look on linux kernel for a thread about this driver not building. This particular module has not changed in about a month. Steve From owner-linux-xfs@oss.sgi.com Tue Sep 11 10:39:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BHdLJ21165 for linux-xfs-outgoing; Tue, 11 Sep 2001 10:39:21 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BHdJd21146 for ; Tue, 11 Sep 2001 10:39:19 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8BHdDJ30952 for ; Tue, 11 Sep 2001 10:39:13 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2944456; Tue, 11 Sep 2001 12:37:57 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA88687; Tue, 11 Sep 2001 12:37:57 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f8BHYeb03033; Tue, 11 Sep 2001 12:34:40 -0500 Message-Id: <200109111734.f8BHYeb03033@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Harrison Xing" cc: linux-xfs@oss.sgi.com Subject: Re: Memory leak in XFS 1.0.1 ? Just mount and umount In-Reply-To: Message from "Harrison Xing" of "Tue, 11 Sep 2001 10:35:47 +0800." Date: Tue, 11 Sep 2001 12:34:40 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi, > > When I mount and umount XFS heavily it seems that there are memory leaks. > After about a day, the machine becomes quite slow and there is little free > memory left, > the buffers and cached memory are almost exhausted. > > for((i=1;i<10,000,000;i++));do > mount -t xfs /dev/hda6 /mnt/xfs > umount /mnt/xfs > done > > I use the 2.4.5 kernel with XFS 1.0.1 release. There does appear to be a slow leak in the mount/unmount path, I have had the loop running for an hour or so now, and memory does appear to be going somewhere. This is with a tree from yesterday's cvs tree. Steve From owner-linux-xfs@oss.sgi.com Tue Sep 11 11:24:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BIO1h21772 for linux-xfs-outgoing; Tue, 11 Sep 2001 11:24:01 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BINud21752; Tue, 11 Sep 2001 11:23:56 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8BINvd21753 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Tue Sep 11 11:48:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BIm3H22126 for linux-xfs-outgoing; Tue, 11 Sep 2001 11:48:03 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BIlId22099; Tue, 11 Sep 2001 11:47:18 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8BIlJd22100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Tue Sep 11 12:27:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BJRZe22733 for linux-xfs-outgoing; Tue, 11 Sep 2001 12:27:35 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BJRXd22713 for ; Tue, 11 Sep 2001 12:27:33 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8BJRRJ03132 for ; Tue, 11 Sep 2001 12:27:27 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2946800 for ; Tue, 11 Sep 2001 14:26:11 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA81670 for ; Tue, 11 Sep 2001 14:26:10 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f8BJMrq03369; Tue, 11 Sep 2001 14:22:53 -0500 Message-Id: <200109111922.f8BJMrq03369@jen.americas.sgi.com> Date: Tue, 11 Sep 2001 14:22:53 -0500 Subject: TAKE - fix min max typing issues Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Clean up type issues with the new min and max macros in xfs. Date: Tue Sep 11 12:25:00 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102597a linux/fs/xfs/xfs_ag.h - 1.39 linux/fs/xfs/xfs_vnodeops.c - 1.511 linux/fs/xfs/xfs_log_recover.c - 1.211 linux/fs/xfs/xfs_mount.c - 1.261 linux/fs/xfs/xfs_dir2_leaf.c - 1.23 linux/fs/xfs/xfs_trans.h - 1.109 linux/fs/xfs/xfs_bmap.c - 1.271 linux/fs/pagebuf/page_buf_io.c - 1.97 From owner-linux-xfs@oss.sgi.com Tue Sep 11 12:42:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BJg8n23146 for linux-xfs-outgoing; Tue, 11 Sep 2001 12:42:08 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BJg4d23127 for ; Tue, 11 Sep 2001 12:42:04 -0700 Received: from ausmail.coremetrics.com ([209.184.141.185]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA08584 for ; Tue, 11 Sep 2001 12:41:56 -0700 (PDT) mail_from (austin@coremetrics.com) Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Sep 2001 14:39:16 -0500 Message-ID: <85063BBE668FD411944400D0B744267A888576@AUSMAIL> From: "Gonyou, Austin" To: "'Steve Lord'" , Harrison Xing Cc: linux-xfs@oss.sgi.com Subject: RE: Memory leak in XFS 1.0.1 ? Just mount and umount Date: Tue, 11 Sep 2001 14:39:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Perhaps another way to do this is to have several bg processes happen and see if the concurrency makes it any order of magnitude worse? -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Steve Lord [mailto:lord@sgi.com] > Sent: Tuesday, September 11, 2001 12:35 PM > To: Harrison Xing > Cc: linux-xfs@oss.sgi.com > Subject: Re: Memory leak in XFS 1.0.1 ? Just mount and umount > > > > Hi, > > > > When I mount and umount XFS heavily it seems that there are > memory leaks. > > After about a day, the machine becomes quite slow and there > is little free > > memory left, > > the buffers and cached memory are almost exhausted. > > > > for((i=1;i<10,000,000;i++));do > > mount -t xfs /dev/hda6 /mnt/xfs > > umount /mnt/xfs > > done > > > > I use the 2.4.5 kernel with XFS 1.0.1 release. > > There does appear to be a slow leak in the mount/unmount > path, I have had the > loop running for an hour or so now, and memory does appear to > be going > somewhere. This is with a tree from yesterday's cvs tree. > > Steve > > > From owner-linux-xfs@oss.sgi.com Tue Sep 11 12:59:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BJx2d23451 for linux-xfs-outgoing; Tue, 11 Sep 2001 12:59:02 -0700 Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BJx0d23432 for ; Tue, 11 Sep 2001 12:59:00 -0700 Received: from scare ([63.231.179.33]) by lips.thebarn.com (8.12.0/8.12.0) with ESMTP id f8BJx6Pp095763 for ; Tue, 11 Sep 2001 14:59:07 -0500 (CDT) Subject: Mandrake RPMs available for testing. From: Russell Cattelan To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 11 Sep 2001 14:52:04 -0500 Message-Id: <1000237926.13368.54.camel@scare> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have placed somewhat current Mandrake rpms on oss. ftp://oss.sgi.com/projects/xfs/download/testing/Mandrake These were compiled with kgcc and should be stable the rpms in RPMSgcc where compiled with: Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/specs gcc version 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk) Which may or may not be stable. If anybody is willing and has the time to stress test these things it would be really helpful in possibly getting XFS included in the next release of Mandrake. I see today mandrake has a new version of the kernel out, so I will respin the rpms to include the latest updates from mdk. Note the version of XFS is the same as the 2.4.8 snapshot patch. I have yet to determine if the top of tree is stable enough and or compatible with 2.4.8+ac but hopefully it is and the next set of rpms will be the latest and greatest bits. From owner-linux-xfs@oss.sgi.com Tue Sep 11 13:10:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BKAoo23914 for linux-xfs-outgoing; Tue, 11 Sep 2001 13:10:50 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BKAdd23895; Tue, 11 Sep 2001 13:10:39 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8BKAed23896 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Tue Sep 11 14:34:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BLY4w25096 for linux-xfs-outgoing; Tue, 11 Sep 2001 14:34:04 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BLXwd25072; Tue, 11 Sep 2001 14:33:58 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |May 14, 2001) at 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8BLXxd25073 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10.09.2001 04:00:30 Adrian Head wrote: [....see subject...] Hi Adrian, I've had a quite similar phenomen last weekend. When copiing with many cp-processes on my xfs-volume i run into io errors or kernel oops. The solution was that the two disks of the Raidsystem are getting to hot when I run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB raid 1 volume). Added another fan and all was fine ;-)........... cu michael From owner-linux-xfs@oss.sgi.com Tue Sep 11 16:08:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BN8Gx26149 for linux-xfs-outgoing; Tue, 11 Sep 2001 16:08:16 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BN8Ce26130 for ; Tue, 11 Sep 2001 16:08:12 -0700 Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA00922 for ; Tue, 11 Sep 2001 16:08:08 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from scare ([63.231.179.33]) by lips.thebarn.com (8.12.0/8.12.0) with ESMTP id f8BMxkPp004045; Tue, 11 Sep 2001 17:59:47 -0500 (CDT) Subject: Re: Mandrake RPMs available for testing. From: Russell Cattelan To: Russell Cattelan Cc: linux-xfs@oss.sgi.com In-Reply-To: <1000237926.13368.54.camel@scare> References: <1000237926.13368.54.camel@scare> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 11 Sep 2001 17:52:43 -0500 Message-Id: <1000248764.13366.113.camel@scare> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 11 Sep 2001 14:52:04 -0500, Russell Cattelan wrote: > I have placed somewhat current Mandrake rpms on oss. > > ftp://oss.sgi.com/projects/xfs/download/testing/Mandrake > > These were compiled with kgcc and should be stable > the rpms in RPMSgcc where compiled with: > Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/specs > gcc version 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk) > > Which may or may not be stable. > > If anybody is willing and has the time to stress test these things > it would be really helpful in possibly getting XFS included in the > next release of Mandrake. > > I see today mandrake has a new version of the kernel out, so I will > respin the rpms to include the latest updates from mdk. Ok so I should have actually looked at the latest cooker rpms before I sent this out. XFS is in the latest cooker rpm! yea! > > Note the version of XFS is the same as the 2.4.8 snapshot patch. > I have yet to determine if the top of tree is stable enough and > or compatible with 2.4.8+ac but hopefully it is and the next > set of rpms will be the latest and greatest bits. > From owner-linux-xfs@oss.sgi.com Tue Sep 11 16:15:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BNFTS26366 for linux-xfs-outgoing; Tue, 11 Sep 2001 16:15:29 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BNFRe26346 for ; Tue, 11 Sep 2001 16:15:27 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.6/8.11.6) id f8BNFLP31401 for linux-xfs@oss.sgi.com; Tue, 11 Sep 2001 19:15:21 -0400 Date: Tue, 11 Sep 2001 19:15:21 -0400 From: Alan Eldridge To: SGI XFS Dev List Subject: cpqfcTSinit.c module build failure Message-ID: <20010911191521.A25147@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have just pulled a fresh CVS copy and the build problem still exists. I'm doing a diff now between my cvs copy from 0908 and today. I tracked it down. Those modules weren't mentioned in the Makefile until now. Bleah. Into my borked-drivers.config file to cut it out of the build. -- Alan Eldridge from std_disclaimer import * From owner-linux-xfs@oss.sgi.com Tue Sep 11 17:08:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8C08VK27163 for linux-xfs-outgoing; Tue, 11 Sep 2001 17:08:31 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8C08Te27141 for ; Tue, 11 Sep 2001 17:08:29 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8C08NJ11048 for ; Tue, 11 Sep 2001 17:08:23 -0700 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA35050 for linux-xfs@oss.sgi.com; Wed, 12 Sep 2001 10:07:06 +1000 (EST) Date: Wed, 12 Sep 2001 10:07:06 +1000 (EST) From: Nathan Scott Message-Id: <200109120007.KAA35050@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - install scripts Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Fix a bug from the folks working on XFS support in the Debian boot floppies. Date: Tue Sep 11 17:03:41 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102627a cmd/attr/install-sh - 1.3 cmd/xfsdump/install-sh - 1.4 cmd/xfsprogs/install-sh - 1.4 cmd/xfsprogs/debian/changelog - 1.27 cmd/acl/install-sh - 1.3 cmd/dmapi/install-sh - 1.5 - Make install-sh posix compliant so ash as /bin/sh works. From owner-linux-xfs@oss.sgi.com Tue Sep 11 23:58:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8C6wPQ00952 for linux-xfs-outgoing; Tue, 11 Sep 2001 23:58:25 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8C6wMe00933 for ; Tue, 11 Sep 2001 23:58:22 -0700 Received: from idcomm.com (IDENT:+HVD84Yp2LWUB3ohupymf+Hr+UrVbq2j@x2-pip82.idcomm.com [209.60.72.93]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f8C78uQ01240 for ; Wed, 12 Sep 2001 01:08:56 -0600 Message-ID: <3B9F080B.F0BBB761@idcomm.com> Date: Wed, 12 Sep 2001 01:00:27 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: lock files after crash Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have an SMP system set to boot to X11/runlevel 5 that is RH 7.1 based (root is XFS). I had a crash at the moment I attempted to start login as a regular user (home is also XFS). It seems that ~/.ICEauthority is written each session when gdm/gnome is used for the login session, and that a check is done for whether or not .ICEauthority can be locked. After a crash, the file is empty (this is ok, it's the metadata versus full journal thing, it isn't an issue), since the crash occurs during that file write. However, after coming back up, X11 will fail due to an inability to lock the file. A question occurs here, whether lock data or whatever information is used to determine if a file can be locked, is part of the filesystem journaling? Or is this a separate issue that can't be dealth with by journaling filesystems? Is there any way XFS, coming back after a crash, can remove stale locks or bogus locks? I have no idea if this is entirely just coincidence it occurs, or if XFS itself can help recover under such circumstances. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Wed Sep 12 00:13:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8C7DNe01341 for linux-xfs-outgoing; Wed, 12 Sep 2001 00:13:23 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8C7DJe01320 for ; Wed, 12 Sep 2001 00:13:19 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id JAA01815; Wed, 12 Sep 2001 09:13:09 +0200 (CEST) Message-Id: <4.3.2.7.2.20010912091115.03368618@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Sep 2001 09:13:06 +0200 To: stimits@idcomm.com, "XFS: linux-xfs@oss.sgi.com" From: Seth Mos Subject: Re: lock files after crash In-Reply-To: <3B9F080B.F0BBB761@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 01:00 12-9-2001 -0600, D. Stimits wrote: >I have an SMP system set to boot to X11/runlevel 5 that is RH 7.1 based >(root is XFS). I had a crash at the moment I attempted to start login as >a regular user (home is also XFS). It seems that ~/.ICEauthority is >written each session when gdm/gnome is used for the login session, and >that a check is done for whether or not .ICEauthority can be locked. >After a crash, the file is empty (this is ok, it's the metadata versus >full journal thing, it isn't an issue), since the crash occurs during >that file write. However, after coming back up, X11 will fail due to an >inability to lock the file. A question occurs here, whether lock data or >whatever information is used to determine if a file can be locked, is >part of the filesystem journaling? Or is this a separate issue that >can't be dealth with by journaling filesystems? Is there any way XFS, >coming back after a crash, can remove stale locks or bogus locks? I have >no idea if this is entirely just coincidence it occurs, or if XFS itself >can help recover under such circumstances. Most of the time lock files are just empty files that get removed when they are done. Netscape also used to do this. But since a lock file might have 0 bytes size it will be committed to disk very fast and journaling or not the file will probably survive a reboot. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Sep 12 01:20:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8C8KJY02470 for linux-xfs-outgoing; Wed, 12 Sep 2001 01:20:19 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8C8KEe02451 for ; Wed, 12 Sep 2001 01:20:14 -0700 Received: from idcomm.com (IDENT:BKGLAaeX7S03fXe0P71JKTdOwZwYLTS5@x2-pip20.idcomm.com [209.60.72.31]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f8C8UTQ06166 for ; Wed, 12 Sep 2001 02:30:29 -0600 Message-ID: <3B9F1B27.49261933@idcomm.com> Date: Wed, 12 Sep 2001 02:21:59 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: Re: lock files after crash References: <4.3.2.7.2.20010912091115.03368618@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > > At 01:00 12-9-2001 -0600, D. Stimits wrote: > >I have an SMP system set to boot to X11/runlevel 5 that is RH 7.1 based > >(root is XFS). I had a crash at the moment I attempted to start login as > >a regular user (home is also XFS). It seems that ~/.ICEauthority is > >written each session when gdm/gnome is used for the login session, and > >that a check is done for whether or not .ICEauthority can be locked. > >After a crash, the file is empty (this is ok, it's the metadata versus > >full journal thing, it isn't an issue), since the crash occurs during > >that file write. However, after coming back up, X11 will fail due to an > >inability to lock the file. A question occurs here, whether lock data or > >whatever information is used to determine if a file can be locked, is > >part of the filesystem journaling? Or is this a separate issue that > >can't be dealth with by journaling filesystems? Is there any way XFS, > >coming back after a crash, can remove stale locks or bogus locks? I have > >no idea if this is entirely just coincidence it occurs, or if XFS itself > >can help recover under such circumstances. > > Most of the time lock files are just empty files that get removed when they > are done. > Netscape also used to do this. But since a lock file might have 0 bytes > size it will be committed to disk very fast and journaling or not the file > will probably survive a reboot. > > Cheers > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. In this case the file is .ICEauthority, not related to Netscape. What I am thinking about is fcntl(). I'm wondering about how these are implemented: F_GETLK, F_SETLK and F_SETLKW. If fcntl locks depend on file structures or metadata, or if the file itself has nothing to do with fcntl? The complaint after failure would seemt to be that it can't set a lock, which is not necessarily the same as file existence. Permissions do not seem to be the problem either. Is the filesystem cooperating with fcntl, and doing the lock storage? Or is this determined in some other way? If the filesystem maintains metadata on locks, then it seems that they should be discarded upon recovery. I'm not concerned with custom schemes like the one you mention (PostgreSQL does this, and it annoys me that after any crash I have to delete the postmaster.pid file...yet "/etc/rc.d/init.d/postgresql status" knows that the "subsystem is locked but postmaster is not running", and it is too stupid to forcibly remove the lock file). D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Wed Sep 12 03:29:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8CATDv05022 for linux-xfs-outgoing; Wed, 12 Sep 2001 03:29:13 -0700 Received: from picklock.adams.family ([145.254.147.58]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8CAT6e05003 for ; Wed, 12 Sep 2001 03:29:06 -0700 Received: from loewe-komp.de (localhost [127.0.0.1]) by picklock.adams.family (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id f8CATT510196; Wed, 12 Sep 2001 12:29:29 +0200 Message-ID: <3B9F3908.F94E9039@loewe-komp.de> Date: Wed, 12 Sep 2001 12:29:28 +0200 From: Peter =?iso-8859-1?Q?W=E4chtler?= Organization: B16 X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.4.9-ac5 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: Michael Wahlbrink CC: linux-xfs@oss.sgi.com Subject: Re: Problems with many processes copying large directories across an XFSvolume. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Michael Wahlbrink wrote: > > On 10.09.2001 04:00:30 Adrian Head wrote: > [....see subject...] > Hi Adrian, > I've had a quite similar phenomen last weekend. When copiing with many > cp-processes on my xfs-volume i run into io errors or kernel oops. > The solution was that the two disks of the Raidsystem are getting to hot when I > run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB > raid 1 volume). Added another fan and all was fine ;-)........... > Hm, every mail from Michael Wahlbrink arrives _7_times_ at the list. Full header follows (no I have no idea why). Why are you sending to linux-xfs AND owner-linux-xfs? From - Wed Sep 12 12:26:06 2001 X-Sieve: cmu-sieve 2.0 Return-Path: Received: from mail.loewe-komp.de (mail.loewe-komp.de [192.168.169.6]) by noisy.loewe-komp.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 9 for ; Tue, 11 Sep 2001 23:19:48 +0200 (CEST) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by mail.loewe-komp.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id for ; Tue, 11 Sep 2001 19:09:46 +0200 Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BH0nJ20501; Tue, 11 Sep 2001 10:00:49 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Tue, 11 Sep 2001 10:00:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BH0hl20488 for linux-xfs-outgoing; Tue, 11 Sep 2001 10:00:43 -0700 Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2] by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BH0ad20469; Tue, 11 Sep 2001 10:00:36 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.2 by out-gate.propack-data.de (Postfix) with ESMTP id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) Subject: Re: Problems with many processes copying large directories across an XFS volume. To: adrian.head@bytecomm.com.au Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Mon, 10 Sep 2001 06:56:01 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.07a |M 10.09.2001 06:56:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8BH0bd2047 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk From owner-linux-xfs@oss.sgi.com Wed Sep 12 04:47:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8CBliq07056 for linux-xfs-outgoing; Wed, 12 Sep 2001 04:47:44 -0700 Received: from mel-rti17.wanadoo.fr (smtprt17.wanadoo.fr [193.252.19.228]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8CBlfe07030 for ; Wed, 12 Sep 2001 04:47:41 -0700 Received: from citronier.wanadoo.fr (193.252.19.222) by mel-rti17.wanadoo.fr; 12 Sep 2001 13:47:34 +0200 Received: from there (193.248.142.125) by citronier.wanadoo.fr; 12 Sep 2001 13:47:16 +0200 Message-ID: <3b9f4b453c427ad2@citronier.wanadoo.fr> (added by citronier.wanadoo.fr) Content-Type: text/plain; charset="iso-8859-1" From: =?iso-8859-1?q?Fran=E7ois=20Dupoux?= To: linux-xfs@oss.sgi.com Subject: Partition Image 0.6.0-rc3 with XFS support Date: Wed, 12 Sep 2001 13:47:13 +0200 X-Mailer: KMail [version 1.3] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk HOMEPAGE: http://www.partimage.org/ DOWNLOAD: http://www.partimage.org/download.php3 HANDBOOK: http://www.partimage.org/doc/index.html Partition Image is a Norton Ghost / Drive Image clone for Linux. This uility saves partitions in the ext2, reiserfs, ntfs, hpfs, fat16, fat32, jfs, xfs, hfs filesystems format to an image file. The image file can be compressed in the GZIP/BZIP2 formats to save disk space, and be splitted to be copied on multiple removable floppies On problems, the user just have to restore the partition from the image file, and all the original data are copied. A boot/root and a bootable CD-Rom disk are now provided to run partition image without Linux installed on the hard disk. The new version provides the newtork support. Tested under intel i386+ and PowerPC/iMac The XFS support has just been added in version 0.6.0rc3. It was a little tested with small partitions (300 MB), and large ones (15 GB), but we need more test to be sure this support is stable. Interested users can make tests and send us bug reports. Tests on large and fragmented partitions are very useful, because the support is more complex. You can have details about how to make advanced tests in the handbook. The partimage team. AUTHORS: Franck Ladurelle Francois Dupoux From owner-linux-xfs@oss.sgi.com Wed Sep 12 06:01:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8CD1GL08399 for linux-xfs-outgoing; Wed, 12 Sep 2001 06:01:16 -0700 Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.127.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8CD1Be08380 for ; Wed, 12 Sep 2001 06:01:11 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp1.xs4all.nl (8.9.3/8.9.3) with ESMTP id PAA14453; Wed, 12 Sep 2001 15:01:08 +0200 (CEST) Message-Id: <4.3.2.7.2.20010912145644.03309ca8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Sep 2001 15:01:05 +0200 To: =?iso-8859-1?Q?Fran=E7ois?= Dupoux , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Partition Image 0.6.0-rc3 with XFS support In-Reply-To: <3b9f4b453c427ad2@citronier.wanadoo.fr> (added by citronier.wanadoo.fr) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8CD1Ce08381 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:47 12-9-2001 +0200, François Dupoux wrote: >HOMEPAGE: http://www.partimage.org/ >DOWNLOAD: http://www.partimage.org/download.php3 >HANDBOOK: http://www.partimage.org/doc/index.html > >Partition Image is a Norton Ghost / Drive Image clone for Linux. This uility >saves partitions in the ext2, reiserfs, ntfs, hpfs, fat16, fat32, jfs, xfs, >hfs filesystems format to an image file. The image file can be compressed in >the GZIP/BZIP2 formats to save disk space, and be splitted to be copied on >multiple removable floppies On problems, the user just have to restore the >partition from the image file, and all the original data are copied. A >boot/root and a bootable CD-Rom disk are now provided to run partition image >without Linux installed on the hard disk. The new version provides the >newtork support. Tested under intel i386+ and PowerPC/iMac > >The XFS support has just been added in version 0.6.0rc3. It was a little >tested with small partitions (300 MB), and large ones (15 GB), but we need >more test to be sure this support is stable. > >Interested users can make tests and send us bug reports. Tests on large and >fragmented partitions are very useful, because the support is more complex. >You can have details about how to make advanced tests in the handbook. I am testing it now since my linux partition still needed to be moved off my old notebook to my new one. This makes it somewhat easier :-) Does partimage also take things like ACLs and other Extended Attributes into account? It looks good and it works right too, impressive. This will make a fast backup solution if some server takes a dump and it needs to be restored. I will test it with a larger filesystem later from a test server which holds some large databases. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Sep 12 06:19:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8CDJKO08960 for linux-xfs-outgoing; Wed, 12 Sep 2001 06:19:20 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8CDJGe08941 for ; Wed, 12 Sep 2001 06:19:16 -0700 Received: from fort.demeern.sgi.com (fort.demeern.sgi.com [144.253.208.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA11278 for ; Wed, 12 Sep 2001 06:19:20 -0700 (PDT) mail_from (martinh@demeern.sgi.com) Received: from poortvliet.demeern.sgi.com (poortvliet.demeern.sgi.com [144.253.208.34]) by fort.demeern.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF.hoststrip-1.1) via ESMTP id PAA28157; Wed, 12 Sep 2001 15:17:52 +0200 (MDT) Received: (from martinh@localhost) by poortvliet.demeern.sgi.com (SGI-8.9.3/8.9.3) id PAA03806; Wed, 12 Sep 2001 15:17:32 +0200 (MDT) Date: Wed, 12 Sep 2001 15:17:32 +0200 From: Martin Hilgeman To: Keith Owens Cc: Florin Andrei , linux-xfs Subject: Re: 1.0.1 doesn't work with SGI1100 Message-ID: <20010912151731.B3756@poortvliet.demeern.sgi.com> Reply-To: martinh@demeern.sgi.com References: <1000175055.23809.155.camel@stantz.corp.sgi.com> <27772.1000176060@kao2.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27772.1000176060@kao2.melbourne.sgi.com> User-Agent: Mutt/1.3.22i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tuesday 11 September 2001, at 12:41 +1000, Keith Owens wrote: > On 10 Sep 2001 19:24:15 -0700, > Florin Andrei wrote: > >ide=nodma solves the problem for the installer. But, after the install, > >when the system comes up for the first time, it's the same problem: it's > >frozen when it tries to mount large partitions. > >I can add to the kickstart file, to the lilo option, the "--append > >ide=nodma" string, and it appears to solve the problem. But, still, if i > >want a high performance from that system (and believe me, i do want > >that, since it's gonna be a busy mail gateway), not using DMA will hurt > >performance. > > It is likely to be a chipset problem rather than XFS. RH 7.1 was > probably compiled without CONFIG_IDEDMA_PCI_AUTO. I used to have the same problem on sgi 1100's. The solution is to patch the kernel with Andre Hedrick's IDE patch, which supports the Serverworks 3LE chipset. The patches can be found on: http://www.linux-ide.org With this patch I get ~16 MB/s on a single Seagate Barracuda ST320420A disk drive. Don't forget to tune with hdparm(8) (hdparm -c3 -d1 -A1 -m16 -X66 works best here). Regards, -Martin -- Martin Hilgeman Technical consultant VNET: 955-6885 SGI Mailstop: INL-3650 The Netherlands E-mail: martinh@demeern.sgi.com From owner-linux-xfs@oss.sgi.com Wed Sep 12 09:06:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8CG66012153 for linux-xfs-outgoing; Wed, 12 Sep 2001 09:06:06 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8CG5se12133 for ; Wed, 12 Sep 2001 09:05:55 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id SAA15539; Wed, 12 Sep 2001 18:05:32 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id SAA09777; Wed, 12 Sep 2001 18:05:21 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 51F4C57306; Wed, 12 Sep 2001 18:04:47 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id F3D9225835; Wed, 12 Sep 2001 18:04:46 +0200 (CEST) Message-ID: <3B9F879E.3FB8976@ch.sauter-bc.com> Date: Wed, 12 Sep 2001 18:04:46 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: stimits@idcomm.com Cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: lock files after crash References: <4.3.2.7.2.20010912091115.03368618@pop.xs4all.nl> <3B9F1B27.49261933@idcomm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "D. Stimits" schrieb: > > Seth Mos wrote: > > > > At 01:00 12-9-2001 -0600, D. Stimits wrote: > > >I have an SMP system set to boot to X11/runlevel 5 that is RH 7.1 based > > >(root is XFS). I had a crash at the moment I attempted to start login as > > >a regular user (home is also XFS). It seems that ~/.ICEauthority is > > >written each session when gdm/gnome is used for the login session, and > > >that a check is done for whether or not .ICEauthority can be locked. > > >After a crash, the file is empty (this is ok, it's the metadata versus > > >full journal thing, it isn't an issue), since the crash occurs during > > >that file write. However, after coming back up, X11 will fail due to an > > >inability to lock the file. A question occurs here, whether lock data or > > >whatever information is used to determine if a file can be locked, is > > >part of the filesystem journaling? Or is this a separate issue that > > >can't be dealth with by journaling filesystems? Is there any way XFS, > > >coming back after a crash, can remove stale locks or bogus locks? I have > > >no idea if this is entirely just coincidence it occurs, or if XFS itself > > >can help recover under such circumstances. At least you're not alone, I was having the same problem. Did you really have a kernel crash? I don't rember what happened in my case but I thought I was upgrading some RPM's and when I rebooted next time I just couldn't login. IIRC I did not have a kernel crash. -Simon > > > > Most of the time lock files are just empty files that get removed when they > > are done. > > Netscape also used to do this. But since a lock file might have 0 bytes > > size it will be committed to disk very fast and journaling or not the file > > will probably survive a reboot. > > > > Cheers > > > > -- > > Seth > > Every program has two purposes one for which > > it was written and another for which it wasn't > > I use the last kind. > > In this case the file is .ICEauthority, not related to Netscape. What I > am thinking about is fcntl(). I'm wondering about how these are > implemented: F_GETLK, F_SETLK and F_SETLKW. If fcntl locks depend on > file structures or metadata, or if the file itself has nothing to do > with fcntl? The complaint after failure would seemt to be that it can't > set a lock, which is not necessarily the same as file existence. > Permissions do not seem to be the problem either. Is the filesystem > cooperating with fcntl, and doing the lock storage? Or is this > determined in some other way? If the filesystem maintains metadata on > locks, then it seems that they should be discarded upon recovery. I'm > not concerned with custom schemes like the one you mention (PostgreSQL > does this, and it annoys me that after any crash I have to delete the > postmaster.pid file...yet "/etc/rc.d/init.d/postgresql status" knows > that the "subsystem is locked but postmaster is not running", and it is > too stupid to forcibly remove the lock file). > > D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Wed Sep 12 09:12:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8CGCuI12410 for linux-xfs-outgoing; Wed, 12 Sep 2001 09:12:56 -0700 Received: from bassia.wanadoo.fr (smtp-rt-5.wanadoo.fr [193.252.19.159]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8CGCpe12348 for ; Wed, 12 Sep 2001 09:12:53 -0700 Received: from amyris.wanadoo.fr (193.252.19.150) by bassia.wanadoo.fr; 12 Sep 2001 18:12:42 +0200 Received: from there (193.248.253.129) by amyris.wanadoo.fr; 12 Sep 2001 18:12:37 +0200 Message-ID: <3b9f89763bea14e4@amyris.wanadoo.fr> (added by amyris.wanadoo.fr) Content-Type: text/plain; charset="iso-8859-1" From: =?iso-8859-1?q?Fran=E7ois=20Dupoux?= To: linux-xfs@oss.sgi.com Subject: Re: Partition Image 0.6.0-rc3 with XFS support Date: Wed, 12 Sep 2001 17:15:06 +0200 X-Mailer: KMail [version 1.3] References: <4.3.2.7.2.20010912145644.03309ca8@pop.xs4all.nl> In-Reply-To: <4.3.2.7.2.20010912145644.03309ca8@pop.xs4all.nl> Cc: Seth Mos MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I am testing it now since my linux partition still needed to be moved off > my old notebook to my new one. This makes it somewhat easier :-) > > Does partimage also take things like ACLs and other Extended Attributes > into account? partimage makes a physical copy of the partition. It's not a simple "tar.gz" of files. In other words, it does the same work than dd does, but it forget to copy all free blocks in order to save space and time. Then everything is kept (bootsector informations, all attributes that can exist, ...) It even keeps location of files on the disk, then the vmlinuz file won't be moved, and LILO will continue to work. regards francois dupoux From owner-linux-xfs@oss.sgi.com Wed Sep 12 09:23:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8CGNiF12758 for linux-xfs-outgoing; Wed, 12 Sep 2001 09:23:44 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8CGNfe12738 for ; Wed, 12 Sep 2001 09:23:41 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id SAA19882; Wed, 12 Sep 2001 18:23:29 +0200 (CEST) Message-Id: <4.3.2.7.2.20010912182157.03348b00@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Sep 2001 18:23:14 +0200 To: =?iso-8859-1?Q?Fran=E7ois?= Dupoux , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Partition Image 0.6.0-rc3 with XFS support In-Reply-To: <3b9f89763bea14e4@amyris.wanadoo.fr> (added by amyris.wanadoo.fr) References: <4.3.2.7.2.20010912145644.03309ca8@pop.xs4all.nl> <4.3.2.7.2.20010912145644.03309ca8@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8CGNge12739 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 17:15 12-9-2001 +0200, François Dupoux wrote: > > I am testing it now since my linux partition still needed to be moved off > > my old notebook to my new one. This makes it somewhat easier :-) > > > > Does partimage also take things like ACLs and other Extended Attributes > > into account? >partimage makes a physical copy of the partition. It's not a simple "tar.gz" >of files. In other words, it does the same work than dd does, but it forget >to copy all free blocks in order to save space and time. Then everything is >kept (bootsector informations, all attributes that can exist, ...) It even >keeps location of files on the disk, then the vmlinuz file won't be moved, >and LILO will continue to work. Cool! I will add it to the FAQ after helping out my sister who is moving. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Sep 12 11:19:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8CIJ8Z15182 for linux-xfs-outgoing; Wed, 12 Sep 2001 11:19:08 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8CIJ2e15163 for ; Wed, 12 Sep 2001 11:19:02 -0700 Received: from idcomm.com (IDENT:18XRkvuzMpCdka/rSOw35tKpuP1+ZImA@x2-pip12.idcomm.com [209.60.72.23]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f8CITcQ20932 for ; Wed, 12 Sep 2001 12:29:38 -0600 Message-ID: <3B9FA793.FCCBC231@idcomm.com> Date: Wed, 12 Sep 2001 12:21:07 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: Problems with many processes copying large directories across an XFSvolume. References: <3B9F3908.F94E9039@loewe-komp.de> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.idcomm.com id f8CITcQ20932 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8CIJ2e15164 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Peter Wächtler wrote: > > Michael Wahlbrink wrote: > > > > On 10.09.2001 04:00:30 Adrian Head wrote: > > [....see subject...] > > Hi Adrian, > > I've had a quite similar phenomen last weekend. When copiing with many > > cp-processes on my xfs-volume i run into io errors or kernel oops. > > The solution was that the two disks of the Raidsystem are getting to hot when I > > run these extensive tests (30cp processes and 15 tar processes on thesame 60 GB > > raid 1 volume). Added another fan and all was fine ;-)........... > > > > Hm, every mail from Michael Wahlbrink arrives _7_times_ at the list. > > Full header follows (no I have no idea why). Why are you sending > to linux-xfs AND owner-linux-xfs? I have the same question. Only I wonder if it is *more* than 7 times each. D. Stimits, stimits@idcomm.com > > >From - Wed Sep 12 12:26:06 2001 > X-Sieve: cmu-sieve 2.0 > Return-Path: > Received: from mail.loewe-komp.de (mail.loewe-komp.de [192.168.169.6]) > by noisy.loewe-komp.de (Postfix on SuSE eMail Server 2.0) with > ESMTP id 9 > for ; Tue, 11 Sep 2001 23:19:48 +0200 > (CEST) > Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) > by mail.loewe-komp.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with > ESMTP id > for ; Tue, 11 Sep 2001 19:09:46 +0200 > Received: from localhost (mail@localhost) > by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BH0nJ20501; > Tue, 11 Sep 2001 10:00:49 -0700 > X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs > Received: by oss.sgi.com (bulk_mailer v1.13); Tue, 11 Sep 2001 10:00:43 > -0700 > Received: (from majordomo@localhost) > by oss.sgi.com (8.11.2/8.11.3) id f8BH0hl20488 > for linux-xfs-outgoing; Tue, 11 Sep 2001 10:00:43 -0700 > Received: from out-gate.propack-data.de (out-gate.propack-data.de > [194.120.230.2] > by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BH0ad20469; > Tue, 11 Sep 2001 10:00:36 -0700 > Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de > [10.2.1.2 > by out-gate.propack-data.de (Postfix) with ESMTP > id CF7C567041; Mon, 10 Sep 2001 06:56:02 +0200 (CEST) > Subject: Re: Problems with many processes copying large directories > across an XFS volume. > To: adrian.head@bytecomm.com.au > Cc: linux-xfs@oss.sgi.com, owner-linux-xfs@oss.sgi.com > X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 > Message-ID: > From: "Michael Wahlbrink" > Date: Mon, 10 Sep 2001 06:56:01 +0200 > X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release > 5.07a |M 10.09.2001 06:56:03 > MIME-Version: 1.0 > Content-type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: 8bit > X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id > f8BH0bd2047 > Sender: owner-linux-xfs@oss.sgi.com > Precedence: bulk From owner-linux-xfs@oss.sgi.com Wed Sep 12 11:27:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8CIRRW15414 for linux-xfs-outgoing; Wed, 12 Sep 2001 11:27:27 -0700 Received: from phobos.pop-star.net (phobos.pop-star.net [64.85.83.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8CIRNe15394 for ; Wed, 12 Sep 2001 11:27:23 -0700 Received: from zerowing.pop-star.net ([208.181.22.52]) by phobos.pop-star.net with asmtp (Exim 3.167 #4) id 15hEl5-00014d-00; Wed, 12 Sep 2001 11:29:11 -0700 Subject: Re: 1.0.1 doesn't work with SGI1100 From: Andy Kwong To: martinh@demeern.sgi.com Cc: linux-xfs In-Reply-To: <20010912151731.B3756@poortvliet.demeern.sgi.com> References: <1000175055.23809.155.camel@stantz.corp.sgi.com> <27772.1000176060@kao2.melbourne.sgi.com> <20010912151731.B3756@poortvliet.demeern.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.13.99+cvs.2001.09.05.07.08 (Preview Release) Date: 12 Sep 2001 11:27:48 -0700 Message-Id: <1000319272.14789.3.camel@zerowing.pop-star.net> Mime-Version: 1.0 X-Authenticated-Sender: andy.kwong@pop-star.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk And you might want to check out the contrib RPMS at http://rpms.aicompro.net As the newer kernels contains serverworks support. These RPMS also have lm_sensors support for hardware monitoring. --Andy On Wed, 2001-09-12 at 06:17, Martin Hilgeman wrote: > On Tuesday 11 September 2001, at 12:41 +1000, Keith Owens wrote: > > On 10 Sep 2001 19:24:15 -0700, > > Florin Andrei wrote: > > >ide=nodma solves the problem for the installer. But, after the install, > > >when the system comes up for the first time, it's the same problem: it's > > >frozen when it tries to mount large partitions. > > >I can add to the kickstart file, to the lilo option, the "--append > > >ide=nodma" string, and it appears to solve the problem. But, still, if i > > >want a high performance from that system (and believe me, i do want > > >that, since it's gonna be a busy mail gateway), not using DMA will hurt > > >performance. > > > > It is likely to be a chipset problem rather than XFS. RH 7.1 was > > probably compiled without CONFIG_IDEDMA_PCI_AUTO. > > I used to have the same problem on sgi 1100's. The solution is to patch > the kernel with Andre Hedrick's IDE patch, which supports the > Serverworks 3LE chipset. > > The patches can be found on: http://www.linux-ide.org > > With this patch I get ~16 MB/s on a single Seagate Barracuda ST320420A > disk drive. Don't forget to tune with hdparm(8) (hdparm -c3 -d1 -A1 -m16 > -X66 works best here). > > Regards, > > -Martin > From owner-linux-xfs@oss.sgi.com Wed Sep 12 14:05:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8CL5Ye19348 for linux-xfs-outgoing; Wed, 12 Sep 2001 14:05:34 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8CL5Ve19326 for ; Wed, 12 Sep 2001 14:05:31 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8CL5P500581 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Wed, 12 Sep 2001 14:05:26 -0700 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA398548 for ; Wed, 12 Sep 2001 23:05:23 +0200 (CEST) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA84297 for ; Wed, 12 Sep 2001 14:10:38 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 890F915A213 for ; Wed, 12 Sep 2001 14:04:06 -0700 (PDT) Subject: Re: 1.0.1 doesn't work with SGI1100 From: Florin Andrei To: linux-xfs In-Reply-To: <20010912151731.B3756@poortvliet.demeern.sgi.com> References: <1000175055.23809.155.camel@stantz.corp.sgi.com> <27772.1000176060@kao2.melbourne.sgi.com> <20010912151731.B3756@poortvliet.demeern.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 12 Sep 2001 14:04:06 -0700 Message-Id: <1000328646.1469.5.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 12 Sep 2001 15:17:32 +0200, Martin Hilgeman wrote: > > Don't forget to tune with hdparm(8) (hdparm -c3 -d1 -A1 -m16 > -X66 works best here). Those parameters are tuned for an 1100? -- Florin Andrei "Our kernel does have source control: its name is Linus Torvalds, CVS with a brain." - Nicholas Knight From owner-linux-xfs@oss.sgi.com Wed Sep 12 14:07:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8CL78j19491 for linux-xfs-outgoing; Wed, 12 Sep 2001 14:07:08 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8CL76e19468 for ; Wed, 12 Sep 2001 14:07:06 -0700 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA01445 for ; Wed, 12 Sep 2001 14:05:38 -0700 (PDT) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA40570 for ; Wed, 12 Sep 2001 14:12:21 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 82E1A15A213 for ; Wed, 12 Sep 2001 14:05:49 -0700 (PDT) Subject: Re: 1.0.1 doesn't work with SGI1100 From: Florin Andrei To: linux-xfs In-Reply-To: <1000319272.14789.3.camel@zerowing.pop-star.net> References: <1000175055.23809.155.camel@stantz.corp.sgi.com> <27772.1000176060@kao2.melbourne.sgi.com> <20010912151731.B3756@poortvliet.demeern.sgi.com> <1000319272.14789.3.camel@zerowing.pop-star.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 12 Sep 2001 14:05:49 -0700 Message-Id: <1000328749.1586.9.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 12 Sep 2001 11:27:48 -0700, Andy Kwong wrote: > And you might want to check out the contrib RPMS at > > http://rpms.aicompro.net Cool! I tried those RPMS and they work fine on a SGI1100 without turning off DMA, which is great. Thanks, -- Florin Andrei "Our kernel does have source control: its name is Linus Torvalds, CVS with a brain." - Nicholas Knight From owner-linux-xfs@oss.sgi.com Wed Sep 12 14:16:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8CLGTm19799 for linux-xfs-outgoing; Wed, 12 Sep 2001 14:16:29 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8CLGQe19777 for ; Wed, 12 Sep 2001 14:16:26 -0700 Received: from idcomm.com (IDENT:ZYqZt4fqjKgeyXSHkuBSnutcYN4V75Q/@x2-pip16.idcomm.com [209.60.72.27]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f8CLR3Q30131 for ; Wed, 12 Sep 2001 15:27:04 -0600 Message-ID: <3B9FD128.AFD7CB83@idcomm.com> Date: Wed, 12 Sep 2001 15:18:32 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: Re: lock files after crash References: <3B9F080B.F0BBB761@idcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "D. Stimits" wrote: > > I have an SMP system set to boot to X11/runlevel 5 that is RH 7.1 based > (root is XFS). I had a crash at the moment I attempted to start login as > a regular user (home is also XFS). It seems that ~/.ICEauthority is > written each session when gdm/gnome is used for the login session, and > that a check is done for whether or not .ICEauthority can be locked. > After a crash, the file is empty (this is ok, it's the metadata versus > full journal thing, it isn't an issue), since the crash occurs during > that file write. However, after coming back up, X11 will fail due to an > inability to lock the file. A question occurs here, whether lock data or > whatever information is used to determine if a file can be locked, is > part of the filesystem journaling? Or is this a separate issue that > can't be dealth with by journaling filesystems? Is there any way XFS, > coming back after a crash, can remove stale locks or bogus locks? I have > no idea if this is entirely just coincidence it occurs, or if XFS itself > can help recover under such circumstances. > > D. Stimits, stimits@idcomm.com Since nobody has said anything, let me rephrase the question. There are custom lock file schemes, which I am not interested in. There *is* fcntl to perform locking. Ignoring lock files, is there any metadata or filesystem data that is altered when using fcntl to lock? If so, it is a "bad thing" to preserve locked status upon recovery...it should be cleared, else the file can't be reopened and locked. During recovery, it can be assumed that the original application no longer should have a lock...it's long dead. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Wed Sep 12 14:29:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8CLTwf20120 for linux-xfs-outgoing; Wed, 12 Sep 2001 14:29:58 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8CLTte20101 for ; Wed, 12 Sep 2001 14:29:55 -0700 Received: from clink-eth.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8CLTn502437 for ; Wed, 12 Sep 2001 14:29:49 -0700 Received: (from roehrich@localhost) by clink-eth.americas.sgi.com (SGI-8.9.3/8.9.3) id QAA67782 for linux-xfs@oss.sgi.com; Wed, 12 Sep 2001 16:28:31 -0500 (CDT) Date: Wed, 12 Sep 2001 16:28:31 -0500 (CDT) From: Dean Roehrich Message-Id: <200109122128.QAA67782@clink-eth.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - put LGPL copyright on cmd/dmapi stuff. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Sep 12 14:28:18 PDT 2001 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfsA The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102694a cmd/dmapi/libdm/dm_session.c - 1.3 cmd/dmapi/libdm/dm_right.c - 1.3 cmd/dmapi/libdm/dm_region.c - 1.3 cmd/dmapi/libdm/dm_rdwr.c - 1.3 cmd/dmapi/libdm/dm_mountinfo.c - 1.3 cmd/dmapi/libdm/dm_hole.c - 1.3 cmd/dmapi/libdm/dm_handle2path.c - 1.6 cmd/dmapi/libdm/dm_handle.c - 1.3 cmd/dmapi/libdm/dm_event.c - 1.3 cmd/dmapi/libdm/dm_dmattr.c - 1.3 cmd/dmapi/libdm/dm_config.c - 1.3 cmd/dmapi/libdm/dm_bulkattr.c - 1.3 cmd/dmapi/libdm/dm_attr.c - 1.3 cmd/dmapi/libdm/dmapi_lib.c - 1.5 cmd/dmapi/libdm/dmapi_lib.h - 1.2 cmd/dmapi/debian/copyright - 1.2 - No Message Supplied From owner-linux-xfs@oss.sgi.com Wed Sep 12 14:32:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8CLW3V20281 for linux-xfs-outgoing; Wed, 12 Sep 2001 14:32:03 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8CLW1e20260 for ; Wed, 12 Sep 2001 14:32:01 -0700 Received: from clink-eth.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8CLVt502613 for ; Wed, 12 Sep 2001 14:31:56 -0700 Received: (from roehrich@localhost) by clink-eth.americas.sgi.com (SGI-8.9.3/8.9.3) id QAA03997 for linux-xfs@oss.sgi.com; Wed, 12 Sep 2001 16:30:36 -0500 (CDT) Date: Wed, 12 Sep 2001 16:30:36 -0500 (CDT) From: Dean Roehrich Message-Id: <200109122130.QAA03997@clink-eth.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - put LGPL copyright on cmd/xfsprogs/libhandle Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Sep 12 14:30:26 PDT 2001 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfsA The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102695a cmd/xfsprogs/libhandle/handle.c - 1.6 cmd/xfsprogs/libhandle/jdm.c - 1.3 cmd/xfsprogs/doc/COPYING - 1.2 - No Message Supplied From owner-linux-xfs@oss.sgi.com Wed Sep 12 15:31:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8CMVja21494 for linux-xfs-outgoing; Wed, 12 Sep 2001 15:31:45 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8CMVee21475 for ; Wed, 12 Sep 2001 15:31:40 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8CMVYJ20675 for ; Wed, 12 Sep 2001 15:31:35 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2943147; Wed, 12 Sep 2001 17:30:18 -0500 (CDT) Received: from lord.americas.sgi.com (lord.americas.sgi.com [128.162.187.39]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA83758; Wed, 12 Sep 2001 17:30:18 -0500 (CDT) Received: from lord.americas.sgi.com by lord.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f8CMUGv02195; Wed, 12 Sep 2001 17:30:16 -0500 Message-Id: <200109122230.f8CMUGv02195@lord.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: stimits@idcomm.com cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: lock files after crash In-Reply-To: Message from "D. Stimits" of "Wed, 12 Sep 2001 15:18:32 MDT." <3B9FD128.AFD7CB83@idcomm.com> Date: Wed, 12 Sep 2001 17:30:16 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > "D. Stimits" wrote: > > > > I have an SMP system set to boot to X11/runlevel 5 that is RH 7.1 based > > (root is XFS). I had a crash at the moment I attempted to start login as > > a regular user (home is also XFS). It seems that ~/.ICEauthority is > > written each session when gdm/gnome is used for the login session, and > > that a check is done for whether or not .ICEauthority can be locked. > > After a crash, the file is empty (this is ok, it's the metadata versus > > full journal thing, it isn't an issue), since the crash occurs during > > that file write. However, after coming back up, X11 will fail due to an > > inability to lock the file. A question occurs here, whether lock data or > > whatever information is used to determine if a file can be locked, is > > part of the filesystem journaling? Or is this a separate issue that > > can't be dealth with by journaling filesystems? Is there any way XFS, > > coming back after a crash, can remove stale locks or bogus locks? I have > > no idea if this is entirely just coincidence it occurs, or if XFS itself > > can help recover under such circumstances. > > > > D. Stimits, stimits@idcomm.com > > Since nobody has said anything, let me rephrase the question. There are > custom lock file schemes, which I am not interested in. There *is* fcntl > to perform locking. Ignoring lock files, is there any metadata or > filesystem data that is altered when using fcntl to lock? If so, it is a > "bad thing" to preserve locked status upon recovery...it should be > cleared, else the file can't be reopened and locked. During recovery, it > can be assumed that the original application no longer should have a > lock...it's long dead. I did respond - twice, but I am operating on a temporary workstation here due to a head crash and my mail setup appears not to be all it could be. In my first message I said: >> Usually part of the start up process of a system should be to clean up >> the junk left behind by the last shutdown/crash/power outage. I >> suspect this is really a case of the cleanup not being there, or of >> the logic in X being a little flakey, the file exists, ergo.... >> >> The only part a filesystem plays in file locking in linux is to store >> the bit in the mode word of the inode that mandatory locking should be >> used, all the rest of the code is above the filesystem level. In my second response, I looked more closely at the code and wrote this: >> There appears to be no filesystem involvement in file locks via fcntl, >> there is no call into filesystem code from the file locking fcntl, so >> I do not see an XFS issue here. Steve > > D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Wed Sep 12 16:47:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8CNluu23234 for linux-xfs-outgoing; Wed, 12 Sep 2001 16:47:56 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8CNlpe23188 for ; Wed, 12 Sep 2001 16:47:51 -0700 Received: from idcomm.com (IDENT:qtuklYToD4LsI97eoHHQWvfJU36y0gct@x2-pip67.idcomm.com [209.60.72.78]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f8CNwSQ29476 for ; Wed, 12 Sep 2001 17:58:29 -0600 Message-ID: <3B9FF4A5.353C87C5@idcomm.com> Date: Wed, 12 Sep 2001 17:49:57 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: lock files after crash References: <200109122230.f8CMUGv02195@lord.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > > > "D. Stimits" wrote: > > > > > > I have an SMP system set to boot to X11/runlevel 5 that is RH 7.1 based > > > (root is XFS). I had a crash at the moment I attempted to start login as > > > a regular user (home is also XFS). It seems that ~/.ICEauthority is > > > written each session when gdm/gnome is used for the login session, and > > > that a check is done for whether or not .ICEauthority can be locked. > > > After a crash, the file is empty (this is ok, it's the metadata versus > > > full journal thing, it isn't an issue), since the crash occurs during > > > that file write. However, after coming back up, X11 will fail due to an > > > inability to lock the file. A question occurs here, whether lock data or > > > whatever information is used to determine if a file can be locked, is > > > part of the filesystem journaling? Or is this a separate issue that > > > can't be dealth with by journaling filesystems? Is there any way XFS, > > > coming back after a crash, can remove stale locks or bogus locks? I have > > > no idea if this is entirely just coincidence it occurs, or if XFS itself > > > can help recover under such circumstances. > > > > > > D. Stimits, stimits@idcomm.com > > > > Since nobody has said anything, let me rephrase the question. There are > > custom lock file schemes, which I am not interested in. There *is* fcntl > > to perform locking. Ignoring lock files, is there any metadata or > > filesystem data that is altered when using fcntl to lock? If so, it is a > > "bad thing" to preserve locked status upon recovery...it should be > > cleared, else the file can't be reopened and locked. During recovery, it > > can be assumed that the original application no longer should have a > > lock...it's long dead. > > I did respond - twice, but I am operating on a temporary workstation here > due to a head crash and my mail setup appears not to be all it could be. > > In my first message I said: > > >> Usually part of the start up process of a system should be to clean up > >> the junk left behind by the last shutdown/crash/power outage. I > >> suspect this is really a case of the cleanup not being there, or of > >> the logic in X being a little flakey, the file exists, ergo.... > >> > >> The only part a filesystem plays in file locking in linux is to store > >> the bit in the mode word of the inode that mandatory locking should be > >> used, all the rest of the code is above the filesystem level. > > In my second response, I looked more closely at the code and wrote this: > > >> There appears to be no filesystem involvement in file locks via fcntl, > >> there is no call into filesystem code from the file locking fcntl, so > >> I do not see an XFS issue here. > > Steve > > > > > D. Stimits, stimits@idcomm.com Is it safe then to say that "...mode word of the inode that mandatory locking should be used..." does not actually get preserved in the metadata? It could be apples and oranges comparison, that mandatory locking should be used, versus actual storage of a bit that says locking has occurred...therefore is it correct that the mandatory locking bit does not actually preserve the idea that a file is currently locked or not locked? If it does preserve anything about the currently locked state, it should probably be cleared after a recovery (it's hard to have a file locked during a recovery...it would be fairly safe to assume no process is actually locking it). D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Wed Sep 12 17:59:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8D0xsV24662 for linux-xfs-outgoing; Wed, 12 Sep 2001 17:59:54 -0700 Received: from shakti.rupa.com (cx838204-a.alsv1.occa.home.com [24.16.83.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8D0xle24642 for ; Wed, 12 Sep 2001 17:59:48 -0700 Received: by shakti.rupa.com (Postfix, from userid 500) id 92804C0098; Wed, 12 Sep 2001 17:59:41 -0700 (PDT) To: linux-xfs@oss.sgi.com Subject: Unable to mount crashed RAID1: bad clientid From: Rupa Schomaker Mail-Copies-To: never Date: Wed, 12 Sep 2001 17:59:41 -0700 Message-ID: Lines: 43 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- After a hard crash under heavy read IO (write to tape) I was unable to mount my /home filesystem (not where the heavy IO was happending). System: Athlon system with VIA motherboard (maybe the root cause of my problems) 4 maxtor 40G drives in two RAID1 40G mirrors. LVM with 1 volume group that spans the two RAID1 slices. /home is in one of the logical volumes in the volume group. Kernel: Debian 2.4.5 + xfs 1.0.1 patches. My kern.log shows: Sep 12 17:07:08 shakti kernel: Starting XFS recovery on filesystem: lvm(58,1) (d ev: 58/1) Sep 12 17:07:08 shakti kernel: XFS: xlog_recover_process_data: bad clientid Sep 12 17:07:08 shakti kernel: XFS: log mount/recovery failed Sep 12 17:07:08 shakti kernel: XFS: log mount failed I "fixed" this by doing a xfs_repair in single user mode. - -- - -rupa -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface iQEVAwUBO6AE9nHDM4ucEopdAQGtrQf/TyvOJPXQq401SZZ54geg31x2Lxkg8kyD Vafi23bxP69TLUTyMN4wydayYX04OEIM6rb6rLsIS0I9qiDz7bvxTzoYAh3C/eGv 1c7hQ+R6sN4Ei4g+A0Y5UpzyqrNRkD0pmuELkyU3xM2G5dS4zbRAtRuPNwUo2q65 TNk22lynfMI8wEjfkYCvnejDkZsw3drVyb2mFGpcscKQtOn+D5J7RWW0lpxe2mwB 0mjJ3MMXqST9PmqTL403w4Hz/yQRRFPdza0HiaySO42SvtAqvdpzMNfiMdHw46I9 9ainap6B3qg3bVqDh3Wz8o+Qovo/RQAvdordqtQLJcq0MahmJpCr8Q== =ZjJ4 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Sep 12 21:55:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8D4tLl28132 for linux-xfs-outgoing; Wed, 12 Sep 2001 21:55:21 -0700 Received: from aquaman.rsp.com.au (unused.rsp.com.au [150.101.94.74] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8D4tHe28113 for ; Wed, 12 Sep 2001 21:55:17 -0700 Received: from [10.5.0.31] (borat.rsp.com.au [10.5.0.31]) by aquaman.rsp.com.au (8.11.2/8.11.2) with ESMTP id f8D4tAq03953 for ; Thu, 13 Sep 2001 14:25:10 +0930 User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 13 Sep 2001 14:25:11 +0930 Subject: RH 7.1 & XFS 1.0.1 on SGI 1200 (AIC7xxx hang) From: Tony Clark To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I've seen mention of this a number of times on the list, but haven't managed to dig up a solution. Please excuse my repetition of the issue. I have a stack of SGI 1200's with 2 x P3 cpus. I can successfully use the XFS 1.0 install disk, but the 1.0.1 disk hangs at the AIC7xxx point. Is there actually a way to make it move past this point using options in lilo, or should I abandon ship and use the 1.0 installer. Thanks, Tony -- Tony Clark e: tony@rsp.com.au Rising Sun Pictures t: +61 8 8364 6074 Adelaide / Sydney f: +61 8 8364 6075 Australia w: http://www.rsp.com.au/ From owner-linux-xfs@oss.sgi.com Wed Sep 12 21:58:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8D4wEh28333 for linux-xfs-outgoing; Wed, 12 Sep 2001 21:58:14 -0700 Received: from sa-bwmail1.storageapps.com (smtp.storageapps.com [63.101.83.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8D4wAe28313 for ; Wed, 12 Sep 2001 21:58:10 -0700 Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Sep 2001 00:56:38 -0400 Message-ID: <23D04BDBA646D411BDDD00D0B774B53902963E49@SA-BWMAIL1> From: "Christian, Chip" To: "Linux XFS (E-mail)" Subject: xfs_repair problems Date: Thu, 13 Sep 2001 00:56:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk All, I'm having trouble at a customer site, where they run RedHat Linux 7.1, XFS 1.0.1 2.4.3 kernel, mounting through RedHat's multipath driver. Linux nas1 2.4.3-SGI_XFS_1.0.1 #1 SMP Thu Aug 30 15:50:24 EDT 2001 i686 unknown Two things happened tonight, not sure yet what was done to cause it, but: the box was refusing to mount three filesystems, claiming duplicate UUIDs. solved this by running xfs_admin -U generate one of the filesystems has a corrupt lost+found; xfs_repair can't fix it: [root@nas2 /]# ls -l /nas2/disk211 ls: /nas2/disk211/lost+found: No such file or directory ls: /nas2/disk211/lost+found: No such file or directory total 12 dr-xr-xr-x 28 root root 4096 Sep 12 09:41 admin drwxr-xr-x 3 root bin 22 Jul 30 10:39 home ... [root@nas2 /]# xfs_repair /dev/md30 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 imap claims a free inode 5700 is in use, correcting imap and clearing inode - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - clearing existing "lost+found" inode - deleting existing "lost+found" entry xfs_repair: phase4.c:1022: delete_orphanage: Assertion `(res == 0 && dirty == 0) || (res == 1 && dirty == 1)' failed. Aborted (core dumped) From owner-linux-xfs@oss.sgi.com Wed Sep 12 22:08:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8D580G28597 for linux-xfs-outgoing; Wed, 12 Sep 2001 22:08:00 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8D57ve28578 for ; Wed, 12 Sep 2001 22:07:57 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8D57q525688 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Wed, 12 Sep 2001 22:07:52 -0700 Received: from yog-sothoth.sgi.com (eugate.neu.sgi.com [144.253.131.5]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id WAA48200 for <@rj.corp.sgi.com:linux-xfs@oss.sgi.com>; Wed, 12 Sep 2001 22:07:51 -0700 (PDT) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id HAA429579 for ; Thu, 13 Sep 2001 07:07:46 +0200 (CEST) mail_from (ajag@snort.melbourne.sgi.com) Received: (from ajag@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA00706 for linux-xfs@oss.sgi.com; Thu, 13 Sep 2001 15:06:30 +1000 (EST) Date: Thu, 13 Sep 2001 15:06:30 +1000 (EST) From: Andrew Gildfind Message-Id: <200109130506.PAA00706@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Improvement request for xfsdump/xfsrestore exit codes Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Incorporate irix6.5f-melb:eoe:06423a from IRIX... Date: Wed Sep 12 22:05:22 PDT 2001 Workarea: snort.melbourne.sgi.com:/home/ajag/isms/slinx The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102719a cmd/xfsdump/common/stream.c - 1.5 - remove MLOG_BARE flags to mlog() cmd/xfsdump/common/qlock.c - 1.3 - change getpid's back to get_pid, remove MLOG_BARE flags, fix mlog_get_hint assert for single-stream/miniroot cmd/xfsdump/common/mlog.c - 1.5 - remove locking from stream_getix, cleanup, comments From owner-linux-xfs@oss.sgi.com Wed Sep 12 22:29:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8D5T0q28966 for linux-xfs-outgoing; Wed, 12 Sep 2001 22:29:00 -0700 Received: from smtp7.xs4all.nl (smtp7.xs4all.nl [194.109.127.133]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8D5Sve28946 for ; Wed, 12 Sep 2001 22:28:57 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtp7.xs4all.nl (8.9.3/8.9.3) with ESMTP id HAA04644; Thu, 13 Sep 2001 07:27:17 +0200 (CEST) Message-Id: <4.3.2.7.2.20010913072344.04338058@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Sep 2001 07:26:53 +0200 To: Tony Clark , From: Seth Mos Subject: Re: RH 7.1 & XFS 1.0.1 on SGI 1200 (AIC7xxx hang) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 14:25 13-9-2001 +0930, Tony Clark wrote: >Hello, > >I've seen mention of this a number of times on the list, but haven't managed >to dig up a solution. Please excuse my repetition of the issue. > >I have a stack of SGI 1200's with 2 x P3 cpus. I can successfully use the >XFS 1.0 install disk, but the 1.0.1 disk hangs at the AIC7xxx point. IIRC you should use the update disk that is available on the ftp site. >Is there actually a way to make it move past this point using options in >lilo, or should I abandon ship and use the 1.0 installer. Hmm, it might be related the noapic option although I don't remember the exact syntax. Head on over to the FAQ or the mailinglist page, there is a link to a searchable mail archive there. I think searching for this type of machine in the list will turn op some results. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Sep 12 22:37:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8D5bSn29230 for linux-xfs-outgoing; Wed, 12 Sep 2001 22:37:28 -0700 Received: from aquaman.rsp.com.au (unused.rsp.com.au [150.101.94.74] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8D5bNe29210 for ; Wed, 12 Sep 2001 22:37:23 -0700 Received: from [10.5.0.31] (borat.rsp.com.au [10.5.0.31]) by aquaman.rsp.com.au (8.11.2/8.11.2) with ESMTP id f8D5b9q04241; Thu, 13 Sep 2001 15:07:09 +0930 User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 13 Sep 2001 15:07:09 +0930 Subject: Re: RH 7.1 & XFS 1.0.1 on SGI 1200 (AIC7xxx hang) From: Tony Clark To: Seth Mos , Message-ID: In-Reply-To: <4.3.2.7.2.20010913072344.04338058@pop.xs4all.nl> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk on 13/9/01 2:56 PM, Seth Mos at knuffie@xs4all.nl wrote: > At 14:25 13-9-2001 +0930, Tony Clark wrote: >> Hello, >> >> I've seen mention of this a number of times on the list, but haven't managed >> to dig up a solution. Please excuse my repetition of the issue. >> >> I have a stack of SGI 1200's with 2 x P3 cpus. I can successfully use the >> XFS 1.0 install disk, but the 1.0.1 disk hangs at the AIC7xxx point. > > IIRC you should use the update disk that is available on the ftp site. I tried, but it never gets to the point where it loads the update disk, and hangs at the point of loading the aic7xxx driver. > >> Is there actually a way to make it move past this point using options in >> lilo, or should I abandon ship and use the 1.0 installer. > > Hmm, it might be related the noapic option although I don't remember the > exact syntax. > Head on over to the FAQ or the mailinglist page, there is a link to a > searchable mail archive there. > > I think searching for this type of machine in the list will turn op some > results. > Hmmm... This was posted: On 18 Jul 2001 15:46:48 -0400, Doug Ledford wrote: > > When using my boot disk, you have to use the "apic" option, not the "noapic" > option. but with no mention of how to use this option. I'll try a little more and see if anything can be made to happen. If anyone who knows how to make this go away, I'd appreciate the assistance. Thanks, Tony From owner-linux-xfs@oss.sgi.com Wed Sep 12 23:02:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8D62Df29678 for linux-xfs-outgoing; Wed, 12 Sep 2001 23:02:13 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8D627e29658 for ; Wed, 12 Sep 2001 23:02:07 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f8D620527473 for ; Wed, 12 Sep 2001 23:02:00 -0700 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA90272; Thu, 13 Sep 2001 16:00:38 +1000 (EST) Date: Thu, 13 Sep 2001 16:00:38 +1000 (EST) From: Nathan Scott Message-Id: <200109130600.QAA90272@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: ag@bestbits.at Subject: TAKE - attr Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a work in progress and is not useful to anyone yet (unless your name is Andreas or Nathan). Eventually this will become the new EA userspace, but there's plenty to be done yet. No kernel support is being made available at this stage as its not all done. cheers. Date: Wed Sep 12 22:53:23 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/attr-linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:102721a cmd/attr2/Makefile - 1.1 cmd/attr2/Makepkgs - 1.1 cmd/attr2/README - 1.1 cmd/attr2/VERSION - 1.1 cmd/attr2/attr/Makefile - 1.1 cmd/attr2/attr/attr.c - 1.1 cmd/attr2/build/Makefile - 1.1 cmd/attr2/build/rpm/Makefile - 1.1 cmd/attr2/build/rpm/attr.spec.in - 1.1 cmd/attr2/build/rpm/macros.template - 1.1 cmd/attr2/build/rpm/rpm-2.rc.template - 1.1 cmd/attr2/build/tar/Makefile - 1.1 cmd/attr2/configure.in - 1.1 cmd/attr2/debian/Makefile - 1.1 cmd/attr2/debian/changelog - 1.1 cmd/attr2/debian/control - 1.1 cmd/attr2/debian/copyright - 1.1 cmd/attr2/debian/rules - 1.1 cmd/attr2/doc/CHANGES - 1.1 cmd/attr2/doc/COPYING - 1.1 cmd/attr2/doc/INSTALL - 1.1 cmd/attr2/doc/Makefile - 1.1 cmd/attr2/doc/PORTING - 1.1 cmd/attr2/getfattr/Makefile - 1.1 cmd/attr2/getfattr/getfattr.c - 1.1 cmd/attr2/getfattr/walk_tree.c - 1.1 cmd/attr2/getfattr/walk_tree.h - 1.1 cmd/attr2/include/Makefile - 1.1 cmd/attr2/include/attributes.h - 1.1 cmd/attr2/include/builddefs.in - 1.1 cmd/attr2/include/buildrules - 1.1 cmd/attr2/include/extattr.h - 1.1 cmd/attr2/include/syscalls.h - 1.1 cmd/attr2/install-sh - 1.1 cmd/attr2/libattr/Makefile - 1.1 cmd/attr2/libattr/libattr.c - 1.1 cmd/attr2/man/Makefile - 1.1 cmd/attr2/man/man1/Makefile - 1.1 cmd/attr2/man/man1/attr.1 - 1.1 cmd/attr2/man/man1/getfattr.1 - 1.1 cmd/attr2/man/man1/setfattr.1 - 1.1 cmd/attr2/man/man2/Makefile - 1.1 cmd/attr2/man/man2/extattr.2 - 1.1 cmd/attr2/man/man3/Makefile - 1.1 cmd/attr2/man/man3/attr_get.3 - 1.1 cmd/attr2/man/man3/attr_list.3 - 1.1 cmd/attr2/man/man3/attr_multi.3 - 1.1 cmd/attr2/man/man3/attr_remove.3 - 1.1 cmd/attr2/man/man3/attr_set.3 - 1.1 cmd/attr2/setfattr/Makefile - 1.1 cmd/attr2/setfattr/setfattr.c - 1.1 - temporary development version of the extended attribute code. From owner-linux-xfs@oss.sgi.com Thu Sep 13 00:56:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8D7uHt31306 for linux-xfs-outgoing; Thu, 13 Sep 2001 00:56:17 -0700 Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.247.6.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8D7uEe31287 for ; Thu, 13 Sep 2001 00:56:14 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id f8D7u5Q22251 for ; Thu, 13 Sep 2001 16:56:05 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id f8D7u3c23833 for ; Thu, 13 Sep 2001 16:56:03 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id f8D7u2F05006 for ; Thu, 13 Sep 2001 16:56:02 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA280 for ; Thu, 13 Sep 2001 16:56:01 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Thu Sep 13 16:56:00 2001 +0900 Received: from rifu.bsd.tnes.nec.co.jp (IDENT:root@rifu.bsd.tnes.nec.co.jp [10.1.101.142]) by mailsv.tnes.nec.co.jp (8.9.3/3.7W01031510) with ESMTP id QAA96932 for ; Thu, 13 Sep 2001 16:56:01 +0900 (JST) Received: from tagajo.bsd.tnes.nec.co.jp (tagajo.bsd.tnes.nec.co.jp [10.1.101.146]) by rifu.bsd.tnes.nec.co.jp (8.10.2+3.3W/3.7W/BSD-TNES-MX01) with ESMTP id f8D7u0L17955 for ; Thu, 13 Sep 2001 16:56:00 +0900 Received: (from sasaki@localhost) by tagajo.bsd.tnes.nec.co.jp (8.8.5+2.7Wbeta5/3.5Wpl1-97090809) id QAA08490; Thu, 13 Sep 2001 16:56:00 +0900 (JST) Message-Id: <200109130756.QAA08490@tagajo.bsd.tnes.nec.co.jp> To: linux-xfs@oss.sgi.com Subject: xfs_estimate Date: Thu, 13 Sep 2001 16:56:00 +0900 From: Takayuki Sasaki Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi there, First of all, thank you for your time to explain xfsdump. I am happy to know about it. Thanks. Today, I have a little question - the default log size of xfs_estimate. The man data of xfs_estimate says it is 10MB, but "xfs_estimate -v foo" says it is 4096000. Which is correct? Cheers. Takayuki From owner-linux-xfs@oss.sgi.com Thu Sep 13 01:36:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8D8aAT32035 for linux-xfs-outgoing; Thu, 13 Sep 2001 01:36:10 -0700 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8D8a8e32016 for ; Thu, 13 Sep 2001 01:36:08 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id f8D8a2505920 for ; Thu, 13 Sep 2001 01:36:02 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA22700; Thu, 13 Sep 2001 19:34:44 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA10274; Thu, 13 Sep 2001 18:34:44 +1000 (AEDT) Date: Thu, 13 Sep 2001 18:34:43 +1000 From: Nathan Scott To: Takayuki Sasaki Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_estimate Message-ID: <20010913183443.A332417@wobbly.melbourne.sgi.com> References: <200109130756.QAA08490@tagajo.bsd.tnes.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200109130756.QAA08490@tagajo.bsd.tnes.nec.co.jp>; from sasaki@bsd.tnes.nec.co.jp on Thu, Sep 13, 2001 at 04:56:00PM +0900 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Sep 13, 2001 at 04:56:00PM +0900, Takayuki Sasaki wrote: > Hi there, > > First of all, thank you for your time to explain xfsdump. > I am happy to know about it. Thanks. > > Today, I have a little question - the default log size of > xfs_estimate. The man data of xfs_estimate says it is 10MB, but > "xfs_estimate -v foo" says it is 4096000. Which is correct? > >From a quick look in the code, it seems the man page is incorrect - the default logsize is 4096 (default blksize) multiplied by 1000 (default log length). xfs_estimate -v -i 4000k xxx ... seems to confirm this. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Sep 13 01:39:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8D8dhf32194 for linux-xfs-outgoing; Thu, 13 Sep 2001 01:39:43 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8D8dee32175 for ; Thu, 13 Sep 2001 01:39:40 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id f8D8dYJ01222 for ; Thu, 13 Sep 2001 01:39:34 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA22710; Thu, 13 Sep 2001 19:38:18 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA57053; Thu, 13 Sep 2001 18:38:17 +1000 (AEDT) Date: Thu, 13 Sep 2001 18:38:16 +1000 From: Nathan Scott To: "Christian, Chip" Cc: "Linux XFS (E-mail)" Subject: Re: xfs_repair problems Message-ID: <20010913183816.B332417@wobbly.melbourne.sgi.com> References: <23D04BDBA646D411BDDD00D0B774B53902963E49@SA-BWMAIL1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <23D04BDBA646D411BDDD00D0B774B53902963E49@SA-BWMAIL1>; from chip.christian@storageapps.com on Thu, Sep 13, 2001 at 12:56:38AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Thu, Sep 13, 2001 at 12:56:38AM -0400, Christian, Chip wrote: > All, > > xfs_repair: phase4.c:1022: delete_orphanage: Assertion `(res == 0 && dirty == 0) > || (res == 1 && dirty == 1)' failed. > Aborted (core dumped) > Its not immediately obvious what the problem is - any chance you can send me me the core file and your xfs_repair binary? (or put them somewhere I can download them?) That'll provide some more clues. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Sep 13 01:42:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8D8gKf32346 for linux-xfs-outgoing; Thu, 13 Sep 2001 01:42:20 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8D8gGe32326 for ; Thu, 13 Sep 2001 01:42:17 -0700 Received: from yavin (yavin.pdc.kth.se [130.237.221.61]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its