On 29 August 2014 22:39, Stefan Fritsch <s...@sfritsch.de> wrote: > On Fri, 29 Aug 2014, Mike Belopuhov wrote: >> correct me if i'm wrong, but what happens is that bread being a block >> read reads up to MAXBSIZE which is conveniently set to 64k and you can't >> create a filesystem with a larger block size. >> >> physio (raw device io) however doesn't go through bread and need to know >> how split the provided buffer in separate transactions hence minphys. > > Yes, that seems to be what happens. But if every adapter needs to support > transfers of MAXBSIZE == MAXPHYS anyway, there would be no need for the > adapter to be able to override the default minphys function with its own. > And adapters that only support smaller transfers would need to have logic > in their driver to be able to split the transfer into smaller chunks. >
i believe that if you start digging you realise that (at least at some point) the least common denominator is (or was) 64k meaning that even the shittiest controller on vax can do 64k. which means that we don't have code for a filesystem or buffercache to probe the controller for a supported transfer size. > I think it makes more sense to have that logic in one place to be used by > all drivers. perhaps, but unless the filesystem will issue breads of larger blocks the only benefit would be physio itself which doesn't really justify the change.
