Date: Fri, 01 Feb 2008 12:27:16 +0200 From: Andriy Gapon <avg@icyb.net.ua> To: Remko Lodder <remko@FreeBSD.org>, scottl@FreeBSD.org, freebsd-fs@freebsd.org Cc: Bruce Evans <bde@zeta.org.au> Subject: Re: kern/84983: [udf] [patch] udf filesystem: stat-ting files could randomly fail Message-ID: <47A2F404.7010208@icyb.net.ua> In-Reply-To: <47A2EDB0.8000801@icyb.net.ua> References: <200612221824.kBMIOhfM049471@freefall.freebsd.org> <47A2EDB0.8000801@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
on 01/02/2008 12:00 Andriy Gapon said the following: > ---- a different, under-debugged problem ----- > BTW, on some smaller directories (but still large ones) I get some very > strange problems with reading a directory too. It seems like some bad > interaction between udf and buffer cache system. I added a lot of > debugging prints and the problems looks like the following: > > read starting at physical sector (2048-byte one) N, size is ~20K, N%4=0 > bread(4 * N, some_big_size) > correct data is read > repeat the above couple dozen times > read starting at physical sector (2048-byte one) N+1, size is ~20K > bread(4 * (N+1), some_big_size) > data is read from physical sector N+4 (instead of N+1) > > I remember that Bruce Evance warned me that something like this could > happen but I couldn't understand him, because I don't understand > VM/buffer subsystem. I'll try to dig up the email. > Sorry for the flood - additional info: if I limit max read size in udf_readatoffset() to 2048 (instead of MAXBSIZE), then large directories can be read OK. Seems like something with overlapping buffers, maybe? BTW, here's how I created test environment for the described issues (in tcsh): mkdir /tmp/bigdir cd /tmp/bigdir set i=1 while ($i < NNNNN) touch file.$i set i=`expr $i + 1` end cd /tmp mkisofs -udf -o test.iso bigdir mdconfig -a -t vnode -f test.iso -S 2048 -u 0 mount_udf /dev/md0 /mnt ls -l /mnt -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47A2F404.7010208>