Date: Tue, 12 Feb 2008 08:53:37 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, Scott Long <scottl@samsco.org>, Pav Lucistnik <pav@FreeBSD.org>, Bruce Evans <bde@zeta.org.au> Subject: Re: fs/udf: vm pages "overlap" while reading large dir Message-ID: <3027.1202806417@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 12 Feb 2008 00:38:12 %2B0200." <47B0CE54.6090204@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <47B0CE54.6090204@icyb.net.ua>, Andriy Gapon writes: >on 06/02/2008 18:29 Andriy Gapon said the following: >> Small summary of the above long description. >> For directory reading fs/udf performs bread() on a (underlying) device >> vnode. It passes block number as if block size was 512 bytes (i.e. >> byte_offset_within_dev/512). We have three sizes of relevance here, the sectorsize of the provider, the blocksize of the filesystem and the page size of the system. In general it is adventurous to have any of them be anything but powers of two, and it is at best ill-adviced and more likely asking for trouble to do requests that are not multiple of and aligned to the sectorsize of the provider. So up front, I would say that it is an UDF bug to do 512 byte reads off a 2k sector provider. Making the buffer cache handle this is possible, but it is not the direction we have planned for the buffercache (ie: that it should become a wrapper for using the VM system, rather than being a separately allocated cache). So if the objective is to make UDF work in the short term, your change might work, if the objective is to move FreeBSD's kernel architecture forward, the right thing to do is to fix UDF to not access subsectors. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3027.1202806417>