Date: Thu, 27 Jul 2006 18:37:25 -0400 From: Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org> To: Alex Zbyslaw <xfb52@dial.pipex.com> Cc: freebsd-hackers@freebsd.org Subject: Re: disklabel differences FreeBSD, DragonFly Message-ID: <17609.16421.670624.80289@bhuda.mired.org> In-Reply-To: <44C93454.5020404@dial.pipex.com> References: <20060727063936.GA1246@titan.klemm.apsfilter.org> <20060727122159.GB4217@britannica.bec.de> <20060727134948.GA3755@energistic.com> <20060727180412.GB48057@megan.kiwi-computer.com> <17609.1474.618423.970137@bhuda.mired.org> <44C910BE.9000108@dial.pipex.com> <20060727185721.GC25626@manor.msen.com> <17609.9516.506115.204334@bhuda.mired.org> <44C93454.5020404@dial.pipex.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In <44C93454.5020404@dial.pipex.com>, Alex Zbyslaw <xfb52@dial.pipex.com> typed: > Mike Meyer wrote: > >> You assume that "running out of space" happens over time, but with some > >>runaway process logging to a file, for example, the partition filling up > >>will still happen without you expecting it. It might take a bit longer > >>with a big disk, but 20 minutes instead of 5 minutes isn't much > >>different in terms of warning. > >Yes, I'm assuming that "running out of space" happens over > >time. Sustained I/O speeds on modern hardware was around 100MB/sec > >last time I looked. So a good, large disk - say a terabyte raid (you > >need raid to get those performance numbers, so call it 2 500GB disks > >to keep it simple) - will take about three hours to fill *if you do > >nothing but write to the disk*. A runaway process - especially one > >generating log data - is normally doing other things that it's trying > >to log information about. > I don't have terabyte raids and for me a "big" disk is 250Gb. In that case, you don't get 100MB/sec of throughput, either. Even if you've got a relatively fast single disk, you're going to be getting maybe 50MB/sec of throughput. So it's *still* going to take hours to fill the disk even if you do nothing but write to disk. And to complete the reprise of the paragraph you elided, if you've got a system that gets a lot more than 100MB/sec to disk, you almost certainly have a lot more disk than a terabyte. > A runaway system demon writing to disk might well do other things. A > badly written user program might do nothing but write to disk. If you > run servers that just run a bunch of standard ports and system demons, > then this is unlikely to happen to you. If you work in an environment > where one or more fallible programmers churn through gigabytes of data > it's depressingly easy to accidentally do *nothing* but write to disk. You know, that's exactly the kind of environment I work in. We churn through gigaROWS of data. We have processes whose sole job is to pull data and write it to disk. Even major failures (like losing the network connection to half the consumer machines) don't cause the disk to fill in minutes. More like days on a properly configured machine. That's because, even if your system is spending *all* of it's time doing nothing but writing to the disk, it'll take hours to fill the disk given most modern disk configurations. Disks have gotten bigger faster than they've gotten faster. So while you used to be able to fill a disk in minutes (or could you?), it takes a really strange configuration to do that now. > >> A further reason to separate partitions is that dump works at the level > >> of a partition. Different partitions may have very different backup > >> requirements, and for those of us without huge tape drives, partitioning > >> to a size that can be dumped on one tape makes life easier. > >That's one of the technical reasons I mentioned in the part you > >didn't quote. > To my mind, it only takes *one* technical reason. If I need multiple > partitions to make backups easy, then arguments about log files are > irrelevant :-) If you're going to count 1, 2, many, then we already have "many" partitions, and don't need more. Once you get into finer distinctions of "many", you need to figure out which reasons are actually valid, and which are spurious, so you can pick from among those manys. > >Well, there are always special cases. But hardware is so cheap these > >days, I'm used to fine-tuning the *system*, not just the partition. > >If something is so critical that it needs it's own partition, it's > >probably so critical that it needs it's own system as well. In fact, > >most of the thing I work on these days are so critical that they need > >several systems, half of them at a second site with automatic failover > >between them. > Not everyone is in a position to throw money at everything and what's > cheap to you isn't cheap to everyone. Boxes are cheaper than disk space - my last two low-end boxes cost less than my last small disk drive, even though I ordered them all about the same time. If you can afford the disk for some process, then chances are good you can afford a system instead, or as well. > I can't possibly justify one system for everything that needs a > partition, nor do I even feel the need to do that. If anything, it > would be a major inconvenience. My claim is that your "everything that needs a partition" probably includes things that don't. But to prove that, we need to examine the reasons you think those things need a partition. I believe the only one you've given so far - as a space firewall - is specious. Your arguments remind me of the environments I worked on in the 70s and 80s. Minis and mainframes that did all the computing for an organization. All the daemons that talked to the outside world ran on the same box as the developers ran compiles and tests on, etc. While that worked really well when it came to generating a robust OS, I haven't seen an environment like that in decades. Hell, most of my clients would shit bricks at the thought of putting their source or data on a machine that could be reached from the internet at large at all. Every developler has a box - or three - on their desks. The ETL boxes are distinct from the database boxes are distinct from the internal mail server is distinct from the external mail server, etc. If I want to have a process send email notices about something, I usually have to beat on them if I want a mail server on the box. And so on.... > >Frankly, if you're really worried about > >bootable slices, you should be advocating giving FreeBSD the ability > >to boot from a logical volume. > Who said I didn't? I have no objection to such a facility and would > welcome it. It just imagined that extending the number of partitions > from 8 to 16 would have been easier than booting from logical slices. > If booting from logical slices is easier then I'm all for it. You're not asking the right question just yet. The question shouldn't be "which is easier to add", but "which provides the most benefit for the least pain" (which subsumes the pain involved in adding it). I believe that the benefits of adding more partitions per slice are minimal - there are at least three ways to add more file systems that aren't bootable, and there's a better fix to the problem of wanting more bootable partitions - and the pain involved in upgrading a system across a change in the bsdlabel would be rather high. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17609.16421.670624.80289>