Date: Thu, 27 Jul 2006 22:47:00 +0100 From: Alex Zbyslaw <xfb52@dial.pipex.com> To: freebsd-hackers@freebsd.org Subject: Re: disklabel differences FreeBSD, DragonFly Message-ID: <44C93454.5020404@dial.pipex.com> In-Reply-To: <17609.9516.506115.204334@bhuda.mired.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. >> 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 :-) >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. 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. >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. --Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44C93454.5020404>