This is a discussion on Re: fs/udf: vm pages "overlap" while reading large dir - FreeBSD ; In message , 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 ...
In message <47B0CE54.email@example.com>, 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.
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
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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"