Date: Fri, 9 Jan 2004 01:55:48 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Chris Pressey <cpressey@catseye.mine.nu>, freebsd-ports@freebsd.org Subject: Re: Call for feedback on a Ports-collection change Message-ID: <p06020445bc23fe841de4@[128.113.24.47]> In-Reply-To: <20040108214759.6fd85d09.cpressey@catseye.mine.nu> References: <Pine.LNX.4.44.0401082157110.30116-100000@pancho> <p06020442bc23e2b0983e@[128.113.24.47]> <20040108214759.6fd85d09.cpressey@catseye.mine.nu>
next in thread | previous in thread | raw e-mail | index | archive | help
At 9:47 PM -0800 1/8/04, Chris Pressey wrote: >On Fri, 9 Jan 2004 00:07:53 -0500 >Garance A Drosihn <drosih@rpi.edu> wrote: > >> Inside the proposed pkg-data file, the patches can have >> whatever names you want. > >Names that you will rarely, if ever, see in a unified diff >between two pkg-data files - I think that's the most common >objection so far. Well, we could fix 'diff' for that... :-) > > Not only that, but you're killing performance when doing >> operations on the entire ports tree (an operation such as >> 'cvsup'). The amount of time to find-and-read ten small >> files is going to be much more than to find-and-read one >> larger file (particularly if that entire larger file can >> still fit in a single block on the disk). > >So fix cvsup :) It isn't an issue with CVSup. It's the reality of disk I/O. There are already people talking about how we will soon have hard disks which are huge and fast, but which you will *never* be able to fill up if you're writing billions of little random-access files. Seek-times and look-up times will completely overwhelm any actual data-transfer times. I'm not saying *that* is a valid justification for doing my project, but I'll try to subliminally get you to think that it is significant without me ever actually saying it is... :-) > > Let me just say that I have some long-term ideas which are > > a bit more ambitious, but this idea is a doable first-step > > towards those ideas. > >Ah, well that's a slightly different goal than "Just reduce >the inode count" isn't it? Well, the inode-count is (IMO) the main justification of *this* project. I didn't want to try to sell this project based on some follow-on project, when I have no idea that I'll ever get to any follow-on projects... >Sorry, I don't mean to sound snarky, No problem. I didn't want to write up a huge message with all the details until I had some feedback on a simplistic overview of the idea. >but when you stated that goal I took it on face value... >and now you go and change it :) > >But actually, I don't see how bundling everything up into a >single (or a couple of) pkg-data file(s) leaves the ports >tree in a more flexible state, either... Well, because you can then add more fields to the new file, without adding more files to the overall ports collection... -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06020445bc23fe841de4>