[fedora-arm] builder io isue

Gordan Bobic gordan at bobich.net
Mon Dec 26 18:39:55 UTC 2011


On 12/26/2011 02:51 PM, Dennis Gilmore wrote:
> El Sun, 25 Dec 2011 22:43:15 -0800
> Brendan Conoboy<blc at redhat.com>  escribió:
>> On 12/25/2011 09:06 PM, Gordan Bobic wrote:
>>> Why not just mount direct via NFS? It'd be a lot quicker, not to
>>> mention easier to tune. It'd work for building all but a handful of
>>> packages (e.g. zsh), but you could handle that by having a single
>>> builder that uses a normal fs that has a policy pointing the
>>> packages that fail self-tests on NFS at it.
>>
>> I'm not acquainted with the rationale for the decision so perhaps
>> somebody else can comment.  Beyond the packages that demand a local
>> filesystem, perhaps there were issues with .nfsXXX files, or some
>> stability problem not seen when working with a single open file? Not
>> sure.
>
> glibc uses functionality not supported on nfsv3.

That may be so, but it does not appear to be in any way an issue for 
having mock chroot on NFS. It also causes no problems with running on 
NFS root. Can you provide a single relevant example of why this is 
relevant for /var/lib/mock?

> nfsv4 may be a viable
> option. mock doesnt work right on nfs.

Can you provide an example? I certainly found no problem with it. The 
only issue I had turned out to be caused by the file system that was 
being exported via NFS having a bug that made the sticky directories not 
work properly. Ever since I fixed that it's been working beautifully.

> i think looking at iscsi or aoe
> or nbd would help to take out some of the layering thats in play
> currently. I really think we need to get more spindles in play. all the
> other arches use raid0 over local scsi/sas drives that are 10k or 15k
> rpm. and the storage is local.  the only local option we have is to use
> USB storage. maybe a 16GB usb stick on each may help. they can be
> gotten for ~USD$16 each we are still going to be limited to the usb bus.

Been there, tried it. Most USB sticks have similar random-write IOPS 
performancs to SD cards (i.e. somewhere between dire and useless). The 
ones that I have found that fare bearably well (i.e. come close to a ~ 
5000 rpm disk) are _some_ of the ones based on a Kingston controller, 
but with the generic no-name sticks you will have to test a large 
selection of models to find a model that is any good.

Gordan


More information about the arm mailing list