problems with readdir in isofs in recent kernels
Robert Schiele
I have experienced problems with readdir in isofs in recent kernels. I found
that sometimes on large directories not all entries appear - no read errors do
occur. If I remount the disc, the missing entries are present. I tried this
with different discs and with different drives, so the problem could not be
related to hardware errors.
Some information about my system that might be usefull:
i686
/proc/version:
Linux version 2.3.99-pre6 (root@schiele) (gcc version 2.95.2 19991024 (release)) #1 Thu Apr 27 08:25:35 CEST 2000
/proc/scsi/scsi:
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: IBM Model: DDRS-39130W Rev: S97B
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 01 Lun: 00
Vendor: SEAGATE Model: ST39140W Rev: 1281
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 02 Lun: 00
Vendor: HP Model: C2520A Rev: 3503
Type: Processor ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 03 Lun: 00
Vendor: IOMEGA Model: ZIP 100 Rev: J.03
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 04 Lun: 00
Vendor: PIONEER Model: CD-ROM DR-U12X Rev: 1.06
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 05 Lun: 00
Vendor: RICOH Model: MP6200S Rev: 2.40
Type: CD-ROM ANSI SCSI revision: 02
/proc/scsi/aic7xxx/0:
Adaptec AIC7xxx driver version: 5.2.0/3.2.4
Compile Options:
TCQ Enabled By Default : Enabled
AIC7XXX_PROC_STATS : Disabled
AIC7XXX_RESET_DELAY : 5
Adapter Configuration:
SCSI Adapter: Adaptec AHA-294X Ultra SCSI host adapter
Ultra Wide Controller at PCI 0/14/0
PCI MMAPed I/O Base: 0xf4000000
Adapter SEEPROM Config: SEEPROM found and used.
Adaptec SCSI BIOS: Enabled
IRQ: 11
SCBs: Active 0, Max Active 17,
Allocated 31, HW 16, Page 255
Interrupts: 1229538
BIOS Control Word: 0x1996
Adapter Control Word: 0x0053
Extended Translation: Enabled
Disconnect Enable Flags: 0xffff
Ultra Enable Flags: 0x0003
Tag Queue Enable Flags: 0x0003
Ordered Queue Tag Flags: 0x0003
Default Tag Queue Depth: 8
Tagged Queue By Device array for aic7xxx host instance 0:
{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}
Actual queue depth per device for aic7xxx host instance 0:
{8,8,1,1,1,1,1,1,1,1,1,1,1,1,1,1}
Statistics:
(scsi0:0:0:0)
Device using Wide/Sync transfers at 40.0 MByte/sec, offset 8
Transinfo settings: current(12/8/1/0), goal(12/8/1/0), user(12/15/1/0)
Total transfers 766190 (437959 reads and 328231 writes)
(scsi0:0:1:0)
Device using Wide/Sync transfers at 40.0 MByte/sec, offset 8
Transinfo settings: current(12/8/1/0), goal(12/8/1/0), user(12/15/1/0)
Total transfers 196670 (94377 reads and 102293 writes)
(scsi0:0:2:0)
Device using Narrow/Async transfers.
Transinfo settings: current(0/0/0/0), goal(0/0/0/0), user(12/15/1/0)
Total transfers 0 (0 reads and 0 writes)
(scsi0:0:3:0)
Device using Narrow/Async transfers.
Transinfo settings: current(0/0/0/0), goal(0/0/0/0), user(12/15/1/0)
Total transfers 2336 (285 reads and 2051 writes)
(scsi0:0:4:0)
Device using Narrow/Sync transfers at 10.0 MByte/sec, offset 15
Transinfo settings: current(25/15/0/0), goal(12/15/0/0), user(12/15/1/0)
Total transfers 231319 (231319 reads and 0 writes)
(scsi0:0:5:0)
Device using Narrow/Async transfers.
Transinfo settings: current(0/0/0/0), goal(0/0/0/0), user(12/15/1/0)
Total transfers 31825 (31825 reads and 0 writes)
If you need some more information, feel free to contact me.
Robert
- --
Robert Schiele mailto:rsch...@uni-mannheim.de
Tel./Fax: +49-621-10059 http://webrum.uni-mannheim.de/math/rschiele/
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQEVAwUBOQ2p9sQAnns5HcHpAQGQ/wf/T8h7EgpyklCgzE+JXzpUZa2KKQygo/09
t3pQ9udU5+bQkAsgtawLxghim8r3tRcsjxWgbM7cpPAHL9dQFITityDdHuNbVMI/
6A0qC/E6+HCloKaNl3CgOncskwt+bCBNS6Sx3nD2wCZXIBmHITpN997qFgQLm6jW
UUdGZT8xU0F9o/vqiIdJhghB6zMThuKTFduS0JD/n9YecZNkkoJESQLx/sfenBju
u9dAkDyECPZ/lCrULGcXO1+9NyCuz5GgwKeAFY7U4Orh1xweQ+LxmtJKKyDH2OZ7
0sX7/pYtbBxXx48akGZCeMf/lK5kgKUdjQk8ObIWPjsLrWZh/hIuZw==
=NdTv
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Oliver Mueschke
> I have experienced problems with readdir in isofs in recent kernels. I found
> that sometimes on large directories not all entries appear - no read errors
> do occur.
this is obviously wrong since 2.1.xx upto 2.3.99
see linux/fs/isofs/dir.c (comments by me):
static int do_isofs_readdir(struct inode *inode, struct file *filp, ....)
{
...
while (filp->f_pos < inode->i_size) {
...
/* this is invalid when offset == bufsize !! */
de = (struct iso_directory_record *) (bh->b_data + offset);
...
/* de is not within the buffer when offset == bufsize */
de_len = *(unsigned char *) de;
...
/* so de_len is not the length of a dir entry, but maybe de_len == 0 */
if ((de_len == 0) || (offset >= bufsize) ) {
brelse(bh);
/* looks like the end of dir entries */
if (de_len == 0) {
...
}
/* here it is too late to handle offset == bufsize,
the wrong conclusion is allready drawn.*/
...
}
offset += de_len;
/* offset == bufsize needs be handled later, but *before* offset is used */
if (offset > bufsize) {
...
}
...
}
}
this was posted at least 2 or 3 times now (first in aug 99) along with a patch.
nobody seems to care. it's discouraging.
oliver
Oliver Mueschke
> I have experienced problems with readdir in isofs in recent kernels. I found
> that sometimes on large directories not all entries appear - no read errors do
since there have been requests to repost the patch, here it comes:
diff -u --recursive --new-file linux-2.3.99-pre7-pre1/fs/isofs/dir.c linux-2.3.99-pre7-pre1-isofspatch/fs/isofs/dir.c
--- linux-2.3.99-pre7-pre1/fs/isofs/dir.c Sun Feb 27 05:33:06 2000
+++ linux-2.3.99-pre7-pre1-isofspatch/fs/isofs/dir.c Tue May 2 09:18:15 2000
@@ -133,12 +133,28 @@
block, offset, filp->f_pos);
printk("inode->i_size = %x\n",inode->i_size);
#endif
+ /* Next directory_record on next CDROM sector */
+ if (offset >= bufsize) {
+#ifdef DEBUG
+ printk("offset >= bufsize\n");
+#endif
+ brelse(bh);
+ offset = 0;
+ block = isofs_bmap(inode, (filp->f_pos) >> bufbits);
+ if (!block)
+ return 0;
+ bh = breada(inode->i_dev, block, bufsize, filp->f_pos, inode->i_size);
+ if (!bh)
+ return 0;
+ continue;
+ }
+
de = (struct iso_directory_record *) (bh->b_data + offset);
if(first_de) inode_number = (block << bufbits) + (offset & (bufsize - 1));
de_len = *(unsigned char *) de;
#ifdef DEBUG
- printk("de_len = %ld\n", de_len);
+ printk("de_len = %d\n", de_len);
#endif
@@ -146,16 +162,11 @@
CDROM sector. If we are at the end of the directory, we
kick out of the while loop. */
- if ((de_len == 0) || (offset >= bufsize) ) {
+ if (de_len == 0) {
brelse(bh);
- if (de_len == 0) {
- filp->f_pos = ((filp->f_pos & ~(ISOFS_BLOCK_SIZE - 1))
- + ISOFS_BLOCK_SIZE);
- offset = 0;
- } else {
- offset -= bufsize;
- filp->f_pos += offset;
- }
+ filp->f_pos = ((filp->f_pos & ~(ISOFS_BLOCK_SIZE - 1))
+ + ISOFS_BLOCK_SIZE);
+ offset = 0;
if (filp->f_pos >= inode->i_size)
return 0;
Linus Torvalds
Oliver Mueschke <o...@mueschke.de> wrote:
>
>this was posted at least 2 or 3 times now (first in aug 99) along with a patch.
>nobody seems to care. it's discouraging.
Note that nobody reads every post in linux-kernel. In fact, nobody who
expects to have time left over to actually do any real kernel work will
read even half. Except Alan Cox, but he's actually not human, but about
a thousand gnomes working in under-ground caves in Swansea. None of the
individual gnomes read all the postings either, they just work together
really well.
Anyway, some of us can't even read all our personal email, simply
because we get too much. I do my best..
What I'm getting at is that if you have the patch, then please re-post.
In fact, cc'ing me is a good idea. And if at first you don't succeed,
try and try again..
Linus
Ricky Beam
>Note that nobody reads every post in linux-kernel. In fact, nobody who
>expects to have time left over to actually do any real kernel work will
>read even half. Except Alan Cox, but he's actually not human, but about
>a thousand gnomes working in under-ground caves in Swansea. None of the
>individual gnomes read all the postings either, they just work together
>really well.
*grin* I always suspected Alan was hiding something under that face of
hair :-) (Kinda like the Ghost of Christmas Future.)
--Ricky
Oystein Viggen
> What I'm getting at is that if you have the patch, then please re-post.
> In fact, cc'ing me is a good idea. And if at first you don't succeed,
> try and try again..
One partial solution to this problem, at least for patches, would be
creating a "linux-kern...@vger.rutgers.edu" which would just add a
"Sender: owner-linux-kernel-patches@..." to the header and forward it to
linux-kernel@. This way, people could sort patches into a different folder
or just "score" them in some way, and it would be easier for everyone to
catch patches. (Sorting on "^Cc:.*torv...@transmeta.com.*" is just plain
old stupid :)
Comments to patches could be handled by forwarding anything matching
"^Subject:.*Re:.*" to linux-kernel and _not_ adding the "Sender:" header
from linux-kernel-patches, possibly also doing a little forgery by doing a
s/linux-kernel-patches/linux-kernel/g or something on the To: and Cc:
fields.
I am of course aware that this solution would not be able to catch all
patches (think about patches posted as replies to questions or other
patches), and it also scores about 9.5 on the 1-10 ugliness scale but I
believe it could help. At least if somebody not me gave it some extra
thought and people could be persuaded into using this system.
I do not think we should need to lose good kernel patches just because
everyone can't be a high availability gnome cluster.
Just my NKR 0.14.
Oystein
wi...@thepuffingroup.com
> One partial solution to this problem, at least for patches, would be
> creating a "linux-kern...@vger.rutgers.edu" which would just add a
> "Sender: owner-linux-kernel-patches@..." to the header and forward it to
> linux-kernel@. This way, people could sort patches into a different folder
> or just "score" them in some way, and it would be easier for everyone to
> catch patches. (Sorting on "^Cc:.*torv...@transmeta.com.*" is just plain
> old stupid :)
the accepted way to do this is put [PATCH] at the start of your subject
line.
Alan Cox
> or just "score" them in some way, and it would be easier for everyone to
> catch patches. (Sorting on "^Cc:.*torv...@transmeta.com.*" is just plain
> old stupid :)
Convention is PATCH: blurb then a diff file attached preferably with a sane
mailer that can include ascii unmangled by quoted-unprintable and which doesnt
eat tabs etc
Alan (Gnome #331)
Steve Dodd
> One partial solution to this problem, at least for patches, would be
> creating a "linux-kern...@vger.rutgers.edu" [..]
There's a really radical extension to this: forbid posting to linux-kernel
at all. Have all the subsystem lists (linux-mm, linux-fsdevel, etc.) forward
posts to linux-kernel. That way people would be forced to classify their
posts (assuming they don't just cc: every list..)