El Mon, 26 Dec 2011 18:39:55 +0000 Gordan Bobic <gordan@xxxxxxxxxx> escribió: > On 12/26/2011 02:51 PM, Dennis Gilmore wrote: > > El Sun, 25 Dec 2011 22:43:15 -0800 > > Brendan Conoboy<blc@xxxxxxxxxx> 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? * Mon Feb 14 2011 Andreas Schwab <schwab@xxxxxxxxxx> - 2.13.90-4 - Update from master - Update sysdeps/unix/sysv/linux/sparc/bits/socket.h - Synchronize generic bits/sched.h cpu_set_t with Linux implementation - Schedule nscd cache pruning more accurately from re-added values - Fix passing symbol value to pltexit callbacks when ld.so auditing - Fix range error handling in sgetspent - Revert "Fix ordering of DSO constructors and destructors" (#673014) - Create debuginfo-common on biarch archs - Reinstall assembler workaround. - Replace setuid by file capabilities (#646469) thats the change that makes it not work, nfsv3 doesnt support file capablities. initing a chroot fails. which means you can not use mock on it. > > > 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. rhel6 is too old to hit the issue. > > 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. I never said it was perfect. just that it may be better that the io bound bottle neck we have right now. Dennis _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
