On Thu, Jan 21, 2010 at 5:23 AM, Pavel Heimlich, a.k.a. hajma <tropikhajma at gmail.com> wrote: > 2010/1/21 Ben Taylor <bentaylor.solx86 at gmail.com>: >> On Wed, Jan 20, 2010 at 7:44 PM, Pavel Heimlich <tropikhajma at gmail.com> >> wrote: >>> I'm not sure if the improvement of several seconds would be worth it. Did >>> you do any benchmarks? >> >> No, but I can tell you unrolling qt-4.6.1 is at least a couple of >> minutes. ?on the smaller ones, >> it's probably negletable. ?The reason I bring it up is that >> continuously unrolling a >> new qt while trying to improve the build means precious minutes every >> build. ?a ZFS >> snapshot revert would make this much faster. > > Hi Ben, > thinking about it again here's something I'd like to add: > 1. this could indeed be helpful with qt (and other giants), it takes 2 > minutes to unpack here - 10 builds means 20 minutes wasted.
this is what I was referring to. small archives probably don't benefit from this, other than to test the logic of the supporting snapshot code. > 2. but it could be very easy to break someone's fs (or break on > someone's fs), because you'll either have to make assumptions on how > the user's filesystem is structured or implement some more complex > algorithms. Certainly I wouldn't want it messing up my fs, I can mess > it up myself well enough without outside help. > I think you could use the tools/build/config file to read the user's > desired fs settings Well, we don't want to break anything on a users' file system. Obviously, the supporting code has to verify that the BUILD directory is on zfs and then manages it. But clearly, this would not be a default, and at best, a developer option. > 3. be aware this is a feature people trying to just build the repo > will not really use / benefit from. agreed. > 3a. using 'tar xzf pkg.tar.gz' is about 30% faster than 'gunzip > pkg.tar.gz && tar xf pkg.tar'. Changing this would benefit everyone. you've tested this? There's probably no harm in doing this, though we have to handle this differently for bz2 version. (Though adding bzip2 support to gtar if it isn't already there would not be difficult. I added it to compress years ago to support bzip2 flar archives since changing the lib stuff for flar installs was much too complicated) > 4. regarding the remark about limitations, I don't think it's a real > problem, we're already limiting ourselves much more in the choice of > compiler and other things. It's reasonable to expect people running > osol and S10u8 to use ZFS. yes. obviously, I would not implement this as the default, since some folks on S10 might be using ufs, or other file systems. > so I think it'd be ok to implement it provided that: > 1. it will not be on by default, perhaps turning it on with something > like --with-snapshots Another option would be to make it spec file dependent, where we know that large archives like qt, and such would benefit from using a zfs snapshot, as opposed to rm -rf'ing and regenerating the directory. then the backend has to verify the criteria (the BUILD directory has to live on zfs, not ufs or nfs... etc) as mentioned above. > 2. the change will be reasonable and easy to maintain - not scattered > throughout 5 files, preferrably a single block of code in a single > file I'm pretty sure, even though I haven't looked, that this would probably reside in two files, one for FOSS and one for KDE. I appreciate the sane, positive and productive feedback from the list. Ben
