Re: Ye Olde optimization/mirror disk space debate
Benoit Peccatte [EMAIL PROTECTED] writes: Do you sometime think at other people's bilities ? I'm sure big mirrors don't care, how about those who can't afford the expense ? Either because their disks are already full and they don't wan't to buy new ones or because buying new ones may mean buying other hardware too or even because bandwidth cost them a lot more tham disk space. Once again, we tell mirrors that they can mirror only i386, and that would be fine. We already have mirrors that mirror some arches and not others, right? Once again, of course, we should do what we can to make this easy for mirrors to handle.
Re: Ye Olde optimization/mirror disk space debate
On Sun, Nov 24, 2002 at 11:45:24AM -0800, Thomas Bushnell, BSG wrote: Once again, we tell mirrors that they can mirror only i386, and that would be fine. We already have mirrors that mirror some arches and not others, right? Currently we have a good, solid mirror infrastructure. I can expect to find one or more full, up-to-date mirrors in my country or a neighbouring country, and I don't even have to look them up -- I just try ftp.*.debian.org, possibly ftp1.*.debian.org, where the * is a country code. You propose to fragment that and make users play hunt-the-right-mirror every time they configure apt. For what benefit? Richard Braakman
Re: Ye Olde optimization/mirror disk space debate
Richard Braakman [EMAIL PROTECTED] writes: On Sun, Nov 24, 2002 at 11:45:24AM -0800, Thomas Bushnell, BSG wrote: Once again, we tell mirrors that they can mirror only i386, and that would be fine. We already have mirrors that mirror some arches and not others, right? Currently we have a good, solid mirror infrastructure. I can expect to find one or more full, up-to-date mirrors in my country or a neighbouring country, and I don't even have to look them up -- I just try ftp.*.debian.org, possibly ftp1.*.debian.org, where the * is a country code. You propose to fragment that and make users play hunt-the-right-mirror every time they configure apt. For what benefit? No. I propose making the solution easy for users and more mirror operators. I can think of several options right off the bat. Moreover, I expect that most mirrors won't skip a beat. Regardless, I have no objection to phasing such things in slowly, as well. Perhaps we wouldn't need both 386 and 486. Perhaps it would be useful to have the easy-local-build variant, since that's a prereq anyway, and it would enable the creation of ready statistics so that the value of optimization can be demonstrated.
Re: Ye Olde optimization/mirror disk space debate
* (Thomas Bushnell, BSG) | 36GB disks? Why buy 36GB disks when you can buy big ones? See, the | problem here is that things are in such frequent motion, that what | seemed like a big disk once is now small. 36GB is a tiny disk. When you are running an ftp server or similar, seek time is more important than data rate. So, you'd rather have ten 36GB disk than two 180GB disks. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Ye Olde optimization/mirror disk space debate
Matt Zimmerman [EMAIL PROTECTED] writes: Say I have 6 36GB disks which cost me $100 apiece (USD600 / 216GB USD2.78 per gigabyte). Naturally, I put them in a RAID-5 array, for 180GB usable space. Now we're at $3.33/GB, not counting filesystem overhead. This is a realistic server configuration, not the pricewatch.com 180GB special for storing Vorbis streams at home. Just drop in a cheap IDE disk is not a realistic solution for this application. 36GB disks? Why buy 36GB disks when you can buy big ones? See, the problem here is that things are in such frequent motion, that what seemed like a big disk once is now small. 36GB is a tiny disk. There are plenty of options. My claim is threefold. 1) The relevant number is how much it costs *us*, provided we do the right thing, and make it simple for mirrors to mirror only what they wish; 2) Complaining about hundreds of megabytes is complaining about trivialities. (I do not dispute that 60GB is worth thinking about.) 3) This discussion requires thinking about actual cost, and not a vague idea of how it must not be useful and would be too expensive. We should think what the cost to us actually is, and then decide if that's too expensive.
Re: Ye Olde optimization/mirror disk space debate
On Fri, 2002-11-22 at 17:07, Thomas Bushnell, BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: Say I have 6 36GB disks which cost me $100 apiece (USD600 / 216GB USD2.78 per gigabyte). Naturally, I put them in a RAID-5 array, for 180GB usable space. Now we're at $3.33/GB, not counting filesystem overhead. This is a realistic server configuration, not the pricewatch.com 180GB special for storing Vorbis streams at home. Just drop in a cheap IDE disk is not a realistic solution for this application. 36GB disks? Why buy 36GB disks when you can buy big ones? See, the problem here is that things are in such frequent motion, that what seemed like a big disk once is now small. 36GB is a tiny disk. 36GB is not so tiny if you think at people who already have a raid arry with this kind of disks. And it's fair for a current SCSI drive. There are plenty of options. My claim is threefold. 1) The relevant number is how much it costs *us*, provided we do the right thing, and make it simple for mirrors to mirror only what they wish; 2) Complaining about hundreds of megabytes is complaining about trivialities. (I do not dispute that 60GB is worth thinking about.) 3) This discussion requires thinking about actual cost, and not a vague idea of how it must not be useful and would be too expensive. We should think what the cost to us actually is, and then decide if that's too expensive. Do you sometime think at other people's bilities ? I'm sure big mirrors don't care, how about those who can't afford the expense ? Either because their disks are already full and they don't wan't to buy new ones or because buying new ones may mean buying other hardware too or even because bandwidth cost them a lot more tham disk space. Do you tell them hey drop debian then, it's not for you ? Not so long ago the local debian mirror I run for a local network was 20Gb and everything was ok, now our free space is narrowed even if we could afford a new disk, we may abandon the mirror because of bandwidth cost.
Re: Ye Olde optimization/mirror disk space debate
Please respect my Mail-Followup-To: header. On Fri, Nov 22, 2002 at 02:07:26PM -0800, Thomas Bushnell, BSG wrote: 36GB disks? Why buy 36GB disks when you can buy big ones? See, the problem here is that things are in such frequent motion, that what seemed like a big disk once is now small. 36GB is a tiny disk. You did not answer the question of how to scale its capacity according to your claims about the cost of disk space, for any size disk. The problem has nothing to do with the increasing size of disks. But to answer your question...because they're popular and economical. 6 36GB disks @ USD100 ea. = USD600 for 180GB RAID-5 (USD3.33/GB) 3 73GB disks @ USD200 ea. = USD600 for 146GB RAID-5 (USD4.11/GB) 4 73GB disks @ USD200 ea. = USD800 for 219GB RAID-5 (USD3.65/GB) Your storage requirements are 120GB and you are on a budget. What configuration do _you_ choose? You seem to be applying desktop PC economics to server problems, which they do not accurately model. IBM makes a 146GB drive for about USD900, by the way. That's USD6.16/GB, and when it dies, it's gone along with all of the data it held. There are plenty of options. My claim is threefold. 1) The relevant number is how much it costs *us*, provided we do the right thing, and make it simple for mirrors to mirror only what they wish; The total cost to us, including the cost of hardware purchase, hardware and software maintenance (more buildd's? faster buildd's?) and increased complexity, is more than enough to require demonstrable benefit before implementing such a system, and the burden of proof is on those who want this to happen. 2) Complaining about hundreds of megabytes is complaining about trivialities. (I do not dispute that 60GB is worth thinking about.) I never made any statements about hundreds of megabytes. Personally, I think that the maintenance and complexity costs far exceed the hardware cost in the long run, but I had a specific objection with your hardware cost estimates. 3) This discussion requires thinking about actual cost, and not a vague idea of how it must not be useful and would be too expensive. We should think what the cost to us actually is, and then decide if that's too expensive. I think that even a conservative estimate of cost is sufficient to show that this idea must be shown to be useful before resources are allocated to it. We should decide whether this even makes sense, and then think about the cost. -- - mdz
