This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Thu Jun 6 11:44:18 2024 Received: from lml.valinux.com (postfix@lml.valinux.com [198.186.203.19]) by herbie.ucs.indiana.edu (8.9.3/8.9.3) with ESMTP id KAA19043 for ; Fri, 21 Jan 2000 10:04:11 -0500 (EST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by lml.valinux.com (Postfix) with ESMTP id 8BA335D272; Thu, 20 Jan 2000 19:41:05 -0800 (PST) Received: by vger.rutgers.edu via listexpand id ; Thu, 20 Jan 2000 21:43:14 -0500 Received: by vger.rutgers.edu id ; Thu, 20 Jan 2000 19:48:21 -0500 Received: from mplspop4.mpls.uswest.net ([204.147.80.14]:4473 "HELO mplspop4.mpls.uswest.net") by vger.rutgers.edu with SMTP id ; Thu, 20 Jan 2000 19:05:03 -0500 Received: (qmail 70728 invoked by alias); 21 Jan 2000 00:04:44 -0000 Received: (qmail 70688 invoked by uid 0); 21 Jan 2000 00:04:43 -0000 Received: from 6401pppd48.mpls.uswest.net (HELO cher) (63.224.23.48) by mplspop4.mpls.uswest.net with SMTP; 21 Jan 2000 00:04:43 -0000 Reply-To: From: "rob herrmann" To: Subject: please speak to your sys admin Date: Thu, 20 Jan 2000 18:10:18 -0600 Message-Id: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001B_01BF6371.9C021660" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu X-Orcpt: rfc822;linux-kernel-outgoing-dig This is a multi-part message in MIME format. ------=_NextPart_000_001B_01BF6371.9C021660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 612.285.7976 robherrmann@uswest.net ------=_NextPart_000_001B_01BF6371.9C021660 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment From: "Keith Bottner" Sender: To: Subject: RE: Interesting analysis of linux kernel threading by IBM Date: Thu, 20 Jan 2000 09:11:38 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <007401bf634c$0a050a30$1f0104c0@maticad> X-UIDL: 948412904.20309.mplspop1.mpls.uswest.net X-Orcpt: rfc822;linux-kernel-outgoing-dig X-Loop: majordomo@vger.rutgers.edu X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-SLUIDL: DF3A077C-C2ED11D3-822E00A0-C9865589 I have been trying to follow this thread but I seem to have missed the URL or reference to the IBM analysis that is under discussion. Could someone who has participated in this message change please repost the URL or the reference? Thanks, Keith Bottner kbottner@istation.com -----Original Message----- From: owner-linux-kernel@vger.rutgers.edu [mailto:owner-linux-kernel@vger.rutgers.edu]On Behalf Of Davide Libenzi Sent: Thursday, January 20, 2000 7:41 AM To: Peter Rival Cc: linux-kernel@vger.rutgers.edu Subject: Re: Interesting analysis of linux kernel threading by IBM Thursday, January 20, 2000 3:14 PM Peter Rival wrote : > No offense, but it is this type of thinking that will keep Linux out of the > datacenter. What you must say it is not a typical (or realistic) workload _for > me_. Hundreds of tasks is trivial here - we have systems running with well over > 100 users actively working that are two or more generations old (that's a much > bigger thing for Alpha than for Intel). On our newer systems we fully expect > hundreds, if not thousands, of tasks. The more commercially accepted Linux > becomes, the more common large configurations are going to be, and we should be > thinking about that now - not when we're being shot all over creation for not > doing what everyone said we could (ala WinNT). > I can only agree here given that there are practically no costs to sustain under normal situations. And improvements are concrete under high load. Cheers, Davide. -- Debian, the freedom in freedom. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ ------=_NextPart_000_001B_01BF6371.9C021660 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment From: "Davide Libenzi" Sender: To: "Khimenko Victor" Cc: References: <022201bf62b0$81cee7d0$1f0104c0@maticad> Subject: Re: Interesting analysis of linux kernel threading by IBM Date: Thu, 20 Jan 2000 10:09:25 -0600 Message-ID: <016601bf6360$b8c63170$1f0104c0@maticad> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0018_01BF6371.9BC69400" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 Importance: Normal X-UIDL: 948412831.13712.mplspop2.mpls.uswest.net X-Orcpt: rfc822;linux-kernel-outgoing-dig X-Loop: majordomo@vger.rutgers.edu X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 This is a multi-part message in MIME format. ------=_NextPart_000_0018_01BF6371.9BC69400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Victor, Thursday, January 20, 2000 4:14 PM Khimenko Victor wrote : > Even 8 tasks is unusual for Desktop. Usually there are 2-3 active tasks. > On other hand Desktop usually is idle all the time anyway so 1.5% looks > affordable for sure. And for server with LOTS of active processes (Apache, > *SQL, etc) it can be real win. > > Where I can find your patch ? I'm in office now and here I've the patch coded for 2.3.5. Anyway this weekend I've planned to port my scheduler into 2.2.14 and 2.3.39 and to post on linux-kernel sunday evening or monday morning ( Europe Time ). This patch also include a semaphore patch that avoid releasing all tasks in a wait queue selecting the best inside wake_up(). Cheers, Davide. -- Debian, the freedom in freedom. ------=_NextPart_000_0018_01BF6371.9BC69400 Content-Type: application/octet-stream; name="patch.diff.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch.diff.bz2" QlpoOTFBWSZTWVNa2KIADkhfgHw0ef////////6/7//+YBXfeBXRZi76668ArQeee715733d6fLH 08PGqa8c1a7M4VLnO22SxZ3G7bJoU3c3bWhtYspDEk1NoI0j00p6J7VN6Ue0k9Jo8ptT1AD1GgGg aADQAlAgBIJPTQ0lHqfqmZR+knpGgfqg0B6nqAA9RoABU1PaKaAAANHqAAAAAANAAAAAkJBEyhpq UexCNqeVND8ppA9R6TQaGgAaaAaA0CJRTBCNpMgAhpNpPSeoephDIDIxNHpAA0aNAkRECMTIhG0I wmKmZIZP1Qegm1NBoaADQNGnLYki8GhAarXhCEm26MDeOqb/JBSYVWo6G1CAypGMHJRShQyqUYxk jqmRqEZI3FOoxdj+DOClkzVNUdsVND4aX7/va4M3X7v1JvW/NiYaibYxNMYD3kaTGUxymqpEjKkK CFOh0IiISRwqkR0xwaTjcGNSSVTolQZCCY2f9vut/U//XnSfyv47bYk/FWj2vMtlREYMbbq1NjzF g6kKxywf760oV7j+P15Ftf8fydLcQK/UPdKymWal5YC+Lfgx04fHpOnNrvMjynHmnG625y5Wl2zN apOJu7uOyWXxIGelTGTcMk0dQiiMTV9XtEbB1tmzkLU4ngafHF7BeQWlsZHbA48u4zS0uSsWLvW4 WVGl5Ws5f0e6NQ5DUaGLdGrWuiWrtHD1qLG+aH2xGOTshtVqKkU4tlWjFca6u2P+fN83DWsOo/jk Oef8Ky2/trw8DOLnPZW2WVMSs7Mcd/uiiXrEIMuogwC+9u34H9dgXoDnSgSuDDLy94nhzf5XA+2c n5nDSNmkmJEFq+bg214FzNXmOgG/dDJynp4RdRg+JSkuBsT2ZqkWGg7d+zufnfA8tCPOceMUPV9O FmqLU6Q5VSoVJGSqqMfIVU6+aEau1C4PoI/dh1dHvv2lrrF0UPNdvssR7mQPay/O+YOqJ021o2m1 fuww2hmxjSOIVNfEWzv+IMNjNsRDJNbGNZSIU29qAIsMZ1x9obzoIQKOI+Nyyw0lRr15uLqeAY3c mvxzo3a5DNIeUwA1qUcX7xoVlwpHBDLXEDTAJh/eoyEN8O/iIgxvcyqGqYxzGhYNrFBuuy1z/kiL LXpp4tzEw1JWBksLsloGPiKCS6y0ojbCB3d4LsuHC7pyRIta5RVD43eviqfg7fGrYqIsbpftoqlW zxvXGpYjrlgBCIgXkbiMqFBKOTNIdOfA4RbQtV2DDsPmy9LXOXO6vcnB6t8JlYbU52lSXlXjMGU9 Np429ewYX10sl6+4YGzjc5tw2nfzpUfBefxMUCLr0/7Lb8XBP9dUk6tmuu4wD5iy8PRzfYXnW/La mjYqNpq8VNr9m6MUK2ocnj1ovBU323zvvmb4N6SVheIsUv29EwR1Aq6GAjpp3whT01m/XIG79pz4 Cz+ui8mm1ZdbEM1oK5IOJDHmfm72TJ8aBFOt59sEldvi64vF5914O1Tm/XafEtWDrVKeW5d6r4UV VU24l3LWFlBychYjxOEyJmonQZeduxHwi1nF71tajdS/7WEUpZ6XkQrBZTIwExnF9ACXHJgR5Xvl pwVjjof5KhOlWxwUNlvmIKFAPUKMy7/NWhS3lLfm77sNVRoVWXEqSY25eipWok6J6s6OyudnVJdy ejO4rCDA9CZgzgUSNjztewutWzwLULeYFvl6nbiR3tv81l1xckWdHDPWuk4DIIThLL2GakhbmmdX udhJLPLLazclSWpNiRJ5xW8PPDUeHHX8Frzrtbs2mFCBj4A8xt6BdqekZj4O6aHw0h945Qyo76dv nRtigYHNCik2mk6LXzix0VOig1D38iuu3tr3ohLXex0JxiEOCKPyG/HLhmG66arwDNQSt1BwPHW1 8kXj6S+JtMlM6nLwV4ZXjrmvRO2JILOeDlJDxlGhIsLDCgD+AUPY5jYLmgx6EjIMmtzLYtf0dRnT SH1JEfn5vcuYuvekTXy60uv/V6VmQ6ToTDuvDhhOib6PU1OXtG1EYpcBMJk/4tcFgTC6Ge+qEjyd oRnNkyV6Ghw6g4ziLz2j0Hu06+1tg2317DCZMeIy8bey7amufkip8+Eeunu/NA0Y0q3nz493lvmr t465b8z5vPaObh5qLOJdGtjRqoiihGThHkw/ZhCUhvLLUVx7txcvLPJb9JPjRjtc5p8JJIkIhEjA gMkIMCLIQJCBAgQZEIQGSQIQATgIDzkI4/UJJIbQl51IAoGYs2uUgICLkQRJGIXRmz48GF2G6+nQ 98m258VKf1ag6WXfjG58rherweQiBzrmSBERLxCeAIBswwJojPhDITKYpTGAigxc5hAMoCT891Zk wyWX0v5EHxdigsU7i8NUwwZZlhhHL74NADy+TkeM76ClUDsogy9WV+s66GNegY5LilRmShPwLp3n JGT5G9GkiSWMmZHqVPbPabMo5wlZpdFHdmwa40tu5pY9S77ttto9oUR4gJcX4niVO0iKFQKKQkcb jT+RkdCg4eAaajGMY8QkNQ77u6+YtkF7E119vZba2n4bhx2/TQrsiFGCsa/78hVLEdtUE443Rss+ Uzg4XqjE4MlLU3DOr97BjE34vUSaYbyh445pVlc0BVw1THBcK2MsXrrDVXCyWWfcCNrHjXWYtdZm Nb6mN7XZtAkX3Kmdt1piEVaNQRtV2mBSm6j2pRlIDO1LJOxDKtL3dp4YqUEw05obmkkVsjlVQMoh Xzue1e7VcoKmV4Oc1gFqAgLY2bSFwXZ+Oxr8duifOiZVKY9TUzKe7Z43GYmdeD6hJqgv03fByLGl IXmyHxuxx6qK5NQti9Zy8eO3BY4KlkWWLZWFBjyVjedwehieWLSKHk81BIRchASEAaEE64AE1T7g EgJ4ATxL/B8/rX1W+v+WxPTcgWCd0ahgtKd/vm7/dpLrYn2+pbMFlpe9SBW4P95szH6l8qw9eNNI 01lx+oGSAZXZDqNSVxGwDSlqGURqWSScihH2P9q2oqaXhyGiK7Kc1uiw4H1WpUus0aSxljB27mFr FuDAnQRhNwCvIB7Wmhh9HJsLKLTUwVWwos2lBxbIRmcpifXS5IBLo/dy2bbYJZmAvH9xGqgzgzBe llAZom1ecuRyuUMSocGBvwKF2CSqK/ZqoCyjd5k5BmEOYSheSJYA0Kg00E96h4J0AmB3AXiMQzCC 1S0sFH+pDIOUaFGPaghL3vL3xhw9vzgvcCla6Pe0v5nFDKhwfqkmCSh0NEyrFIWZMgU5Ok6Dqiap SdRGkUpGcuRKnfNVdt9vk+o50o8qFVJ8wfPfQC1OrcFUWTCaRa1UwJrUgBoSID7pwuLgjJivhabY 21sYP3/JYyn/A2D8NGyFs0dAIoZFR0NWZSdyyiY07CcekDLbWoQ1LGL8Up0W7h2Lr5yf1HQkVMlV UYuLrO8JCMn9ASqiBgijHtDTplFQcokT99DkZahVUQUQ2QbCIVSMg7TmmskJyaKdE6yYldiSc4RG KvxbYMsS9AMbbEgMpOiohNRm5HZMmaIGOPChuoCUXiyW6tjQhuOwwzW3yYNmuLKcrSHuKqRSKfpa YTdB06FhdL0i9d6/z8X37rYRkanx5jKbe/sZA8jDwhhdlgqd39BoFfpq45LmqF6uL8EJOrvsrCEQ xT2BAfj7ZRNxbbLpk0z0aFTRdRBujC4qaOwHJznLr3Ue2urGcFRSbgOPWigdDCHfehS1nVKOU2NX tH7lm6s8A0XYHkFI1SjMpPQ7SDyTAYwvLg0Cu25Yf8ESW6lA2sD86dB4IQWembzN94kF4IsteHE8 fA6WS0QYFdIfJPIwQoL4tCWWrSD0ooXLknVIHtcpOv/lrZVJ3V1NoPwmrb1KbDDKt6q4TWBUR+3B U0ouKR9J9YYxOlEb2IwDZzTEX1Z3EF4AvBGGUUqLDsKQFYXgQz0xDuwiRGYlJJio4Oqzkiu14mSq 0qNo8/quFMvGd8rUZbWpdtctF2e5kokdQqtQhj4VewG9dKCFs7WTbqqljXrqwhMakK1JQBTnK+TD YU5uKpkVQss7siwbgaOFq3jXKjpAeN9trIRsfDmN5GxFnac4uYqsrdzxpDk6UbZu4lGzCWRItcCh JCS13WUTShzVOakRRdzaqxlCUIG1RAxDLZfow3bbEnCoGiqrlm/M7q2gsU5pkAHHSKFrt0XkUtSs u69a2MXWyhDjbWtvQFIGXP7hzWyDQ2YvKyJKVkjbT72HzFNsZG3gCLTINzQ5DQG2ChBWoILkvs76 qhaEetcx8IdPS5h0lHOmqkMBsqYuHdCryQqWC8wkTuxkEIRSt2Pv0P1QtoJLB6fFhxpXworeFGaV ptCxERsbQeAOXcAPu8DkR0CYJlDu+gjgmI8GXuzvynaAPbL9Wz2y/YA3j1EHvTsRWd7oW1mjPDDm Vqjn5zu0oRPMnbLwxObrBuncIXj2ghwGDRA9BUfrCTAa7oEV6UFvv60pnwkVemafAUq1ZJ1HQvYD yHEINHLY/S4Orqhc9dFYtgBiIzN2R372KazBdUIMgwkkWAcrmUq6zYKb9UqKRLzI5y4oSrhfqtl8 dqsFAc5AB3iCITSTAcBomYKIaBRInBQ7AGiyR26fSsQQ22HTO0CzljcL68iBcMfHpGelJ9Fokjmb BwhmLs51m5MC02N7UhYZQcQmJJFzDv0Y0xh8TCBgX0sBXtEfeIlt58KnEZoAg92Bot2JcFDYbwsi Gnlz+a9S7CBhRkKG7SMGNI4PQxSsKolOkpJS0nPqiQlVkqVFRo7EjGfyMHCBe8e3MUpdoC2ztYoc JWSxKlkoxRRSw6bdFldLDZYLJ3LncL5eNxaGcFERTGyoHm4XVgHfrgLgJgM4KbQ2gU6EIJX3d3wt 9s0VB9EJnGHSLLCxSlYLlkkwzJIkgEIBspjvjUWkQ1NgwKTDUYRIObbBSxyOCQyIqxAsrWpDcHZq IiQlNSi2QCutDl87ODQ2smBLG0AyDqngptnZyZ6oO8C8A8UdKIclqntAHK+HBNmOCa24iQxIOfep ZUNiqWlxYbQ+eKkg2mZuLDy9KJYGSZs9sdryiyIMjkqjeKpuySNWCGNCvPkDPGtQNEDSD7a5fTij YIvz83yzdOaRNdv191z2+4g6bht3HmDCnrGlzZaaFmJl9JZR0GpackVrRLxbONDz0u948aXPaWd4 Xq5SWwoVDLrQE3JFjyxZkOtEVPFkpsVoxKExYYma5kqUM+RfHty+Fek6ydFgDIIFKuM+w6w6yLJd 9ZEmiufLqGugSpRsGSmbFWstooxg2MY7gwkhCamxYXhjqyFqUZBkelpLZQsHD8dD0VWQw6OvjhRD 0WqI0KY7P14nrlXGCAM8DuEzs5vZXktPOW5AURURVAtUNMa7tKbqWrswuWpgjgwzqDeXKRIEizbU 705JaZbwSzEvZHa0yh1KNhej2UezHfWRhZqsmRR8WFT5zHNhvFMw0ebSWqYE8MgkO9TR4ZVrkzI7 ThSDtVwY22+gZfEDoYItmILLmEvIpMHYqOgeGPSBF4tsKbMaENkwTTXbJNJJquvRcheFFmFjQNmv LC21sGnosPU888YK+HdCQWGgaQUc4zyBCiJtngfAaFDogdmEkKiWtRxa4OKqUYrxMdmjQ1w7Iuht oc1DT2Mgas8DiQaY0/o77NBS/MyrQRFkXG9sGNDQOFjUL8KKcKPEhIyEdb5ITZkYNuIXsRZDjEyI Zwxl1ylEO+tU7SPyLLlizxFs4V6M67mg3es5N7iRa90Nu8g0d5Kvi/3DU0LFmHOOzyOZeLrGOBkK MYzh74EOiyKGXVD5gI2RKyCG1Fz6FBqZXGZgtMG9WxQsVkTSa6pSCnIRaiVzwRgjBgzEcKSksrky sihptnW5dgwb6FaALdCRduJkjLLEdF7ZrM2N0vS8vtA3HsB4HA3Ge3CAizY22wGDS5c5o6L2hSQL UwHlG3tcJkgxnWnyItrWV9WQaDO3PBWxQ3wwxcjQOKQLkGqbAbAXKoFxpKb+wnECa+gOnbzn/DFC 8zDutQHXuFBEKiWbKrGumWqKILq9G4ndAjWvBjHoAZJJWhJyeEFw0FVWVEJELmJChxJ3/sdqBmsJ 2KFeUtKKbc97oohuRLFjni5Yn03hQtlD0e2Nppo12AoTBnBh3jCgNIF5tj4tdjrQmGHVHPJDRbQr 1ViOi3YhYkGmbQmM7hsGvrIeyHHZRCa+MopcMyT9ilfSf+LuSKcKEgprWxRA ------=_NextPart_000_0018_01BF6371.9BC69400-- ------=_NextPart_000_001B_01BF6371.9C021660 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment From: "Giulio Orsero" Sender: To: Subject: scsi tape: does kernel give wrong info to cpio? Date: Thu, 20 Jan 2000 09:53:31 -0600 Organization: nowhere Message-ID: <20000120155346.EE5E6887E@i3.golden.dom> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Forte Agent 1.7/32.534 Importance: Normal X-UIDL: 948412372.1645.mplspop2.mpls.uswest.net X-Orcpt: rfc822;linux-kernel-outgoing-dig X-Loop: majordomo@vger.rutgers.edu X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 I'm posting here because redhat/bugzilla moved my bug report from cpio to kernel, so they think this is a kernel/scsi issue. == kernel 2.2.14, cpio-2.4.2-13 (rh61) scsi_mod, aha152x, st as modules SCSI controller: Adaptec AVA-1050 SCSI tape unit: Tandberg SLR2 525MB PROBLEM: I can do multivolume cpio backups on tape, but then I cannot restore them due to cpio problems, maybe due to the kernel. I use these commands: Backup: find /path|cpio -ovHcrc -O /dev/st0 - it starts to backup then it asks me for a 2nd tape with: "Found end of tape. Load next tape and press RETURN." I insert the 2nd tape and the backups ends regularly with the message about the blocks copied. Restore: cpio -ivdumHcrc -I /dev/st0 - it asks me for the 2nd tape with: "Found end of tape. Load next tape and press RETURN." - then asks me for a 3rd tape!!, with: "Found end of tape. Load next tape and press RETURN." Since I have not a 3rd tape (the backup took 2 tapes only), I simply press enter (_leaving_ the 2nd tape IN) "cpio: read error: No medium found" (the 2nd tape is in). Note that: - The stuf restored is only 5/10k smaller than the original size,very little but the restore is unreliable. - the backup took very little of the 2nd tape (say 10MB). - I even tried with -B 5120 - I tried with different tapes (3M), different controllers (all ISA adaptec with module aha152x.o) and different tape units (all Tandberg) I found an article on dejanews by Kai Mäkisara regarding problems with cpio multivolume restore with kernels 2.0.x (cpio quits as soon as it arrives at the end of the 1st tape with an I/O error). I found nothing regarding kernels 2.2.x. ===begin deja article on 2.0.x kernels On Tue, Mar 24, 1998 at 11:26:10AM +0100, Stephane KLEIN wrote: > But the restoring (cpio -i ..) fails at the end of the first tape with a > read IO error. I think this is a known bug in 2.0.X. The following message is from Kai Mäkisara, maintainer of the SCSI tape driver: | On Wed, 28 May 1997, Jan Echternach wrote: | > There is a problem with taper not detecting the end of tape. With my | > SCSI DAT drive and kernel 2.0.30, read() returns 0 only one time, and | > all subsequent reads return EIO. It seems that ftape returns _two_ | > times 0, which taper handles correctly. | > | ... | > | > Do 2.1.x kernels return two times 0? If so, should 2.0.30 also return | > two times 0 at end of tape? | > | What should happen, according to the BSD semantics, is this: | - at filemark, the first read returns 0 bytes, the second read returns | data from the next file | - at EOD, the first and the second read return 0 bytes, the third returns | error (-1) | i.e., 2.1.x operates correctly. | | The EOD behaviour was fixed at 2.1.20. In principle, it should be fixed | also at 2.0.31 but I think the risks are too big: fixing EOD behaviour | may break something else (the fix from 2.1.20 can't be used directly). | | Kai ===end deja article Thanks. -- giulioo@pobox.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ ------=_NextPart_000_001B_01BF6371.9C021660-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/