Re: disklabel differences FreeBSD, DragonFly
: :* Matthew Dillon ([EMAIL PROTECTED]) wrote: : : felt that 8 partitions is restrictive. My main home server has 10 : and the main DragonFly box has 11. : : There is another solution for FreeBSD folks, however. You *DO* have : four slices to play with. You can put a disklabel with 8 partitions : in it on each one (for 32 total). It isn't as convenient, but it does : work. :About `lack' of partitions - don't forget that labels can be nested. :Just do `bsdlabel -w /dev/ad0s1e` - you'll get /dev/ad0s1ea. : :-- :Best regards, : Dmitry mailto:[EMAIL PROTECTED] Oh, very cute! A terrible hack if you ask me, but cute all the same! -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
In message: [EMAIL PROTECTED] Andreas Klemm [EMAIL PROTECTED] writes: : Incompatible to UFS's like from Sun I think we are already, so we : don't have to honour them. Remember a current thread in german BSD : group where somebody complained about FreeBSD - mounting a Sun : filesystem r/w - destroyed the filesystem. Luckily he could recover : using fsck -b 32. I'm surprised that the fsck code passed the magic number test, since the sun ufs is in a different endian.. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
* Matthew Dillon ([EMAIL PROTECTED]) wrote: Oh, very cute! A terrible hack if you ask me, but cute all the same! I don't consider it a hack. Pretty expected and consistent behaviour - any block device (be it a whole disk or just a partition) is scanned by geom for magic numbers, and if any found, corresponding subdevices do appear. This gives amazing flexibility - you can choose whether to use any partitioning scheme (you can drop slices at all), you are not limited to 4 slices * 7 partitions. Also, you may dd a whole disk image into partition of enough size, and still be able to mount subpartitions of that image (or boot qemu from it) without md(4) overhead (of course MBR slices can be nested as well - you'll get ad0s1s1 or ad1s1as1). Very cute indeed :) -- Best regards, Dmitry mailto:[EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
Dmitry == Dmitry Marakasov [EMAIL PROTECTED] writes: Dmitry * Matthew Dillon ([EMAIL PROTECTED]) wrote: felt that 8 partitions is restrictive. My main home server has 10 and the main DragonFly box has 11. There is another solution for FreeBSD folks, however. You *DO* have four slices to play with. You can put a disklabel with 8 partitions in it on each one (for 32 total). It isn't as convenient, but it does work. Dmitry About `lack' of partitions - don't forget that labels can be Dmitry nested. Just do `bsdlabel -w /dev/ad0s1e` - you'll get Dmitry /dev/ad0s1ea. Don't also forget that gpt(8) exists and seems to provide for large numbers of partitions. It even seems to be compiled into GENERIC by default. Dave. -- |David Gilbert, Independent Contractor. | Two things can be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
* David Gilbert ([EMAIL PROTECTED]) wrote: Dmitry About `lack' of partitions - don't forget that labels can be Dmitry nested. Just do `bsdlabel -w /dev/ad0s1e` - you'll get Dmitry /dev/ad0s1ea. Don't also forget that gpt(8) exists and seems to provide for large numbers of partitions. It even seems to be compiled into GENERIC by default. Afaik, one is unable to boot from gpt partitions. However, I myself didn't try it yet. Do gpt fully eliminate need in mbr/bsdlabel partitioning? There is also issue with UFS filesystems and bsdlabel - some filesystem data is stored in label itself: # bsdlabel /dev/ad0s1 #size offsetfstype [fsize bsize bps/cpg] a: 26214404.2BSD 2048 16384 16392 ~~ For example, fsck(8) makes use of it - you can newfs /dev/ad0s1a fsck /dev/ad0s1a but you can't newfs /dev/ad0 fsck /dev/ad0 the latter will complain about unknown filesystem type and you'll have to use fsck_ufs instead. This shouldn't affect automatic fsck (because of fstab), but I can't guarantee that there are no any other drawbacks. -- Best regards, Dmitry mailto:[EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
: : Dmitry == Dmitry Marakasov [EMAIL PROTECTED] writes: : :Dmitry * Matthew Dillon ([EMAIL PROTECTED]) wrote: : felt that 8 partitions is restrictive. My main home server has 10 : and the main DragonFly box has 11. : : There is another solution for FreeBSD folks, however. You *DO* : have four slices to play with. You can put a disklabel with 8 : partitions in it on each one (for 32 total). It isn't as : convenient, but it does work. : :Dmitry About `lack' of partitions - don't forget that labels can be :Dmitry nested. Just do `bsdlabel -w /dev/ad0s1e` - you'll get :Dmitry /dev/ad0s1ea. : :Don't also forget that gpt(8) exists and seems to provide for large :numbers of partitions. It even seems to be compiled into GENERIC by :default. : :Dave. Yah, well... I'd be a bit leery of using anything more complex then a basic disklabel. The more complex the setup, the more likely that a disk crash will become unrecoverable. I had an issue a little while back with a disk crash where the OS's insistence on reading numerous sectors at both the beginning and end of the disk before 'recognizing' it as a disk prevented me from being able to access the disk at all, even when all I wanted to do was to make a disk image of e.g. '/dev/ad6' and skip over the bad sectors. It pissed me off so much I rewrote the code in DragonFly to not actually try to interpret a slice or partition table unless something needing the slice or partition table was accessed (like '/dev/ad6s1'). A linked or recursive partition table makes things all that much more fragile. Recursion isn't as big a deal as linking. Linked partition tables are a disaster waiting to happen. No thanks! -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
Dmitry Marakasov [EMAIL PROTECTED] writes: Afaik, one is unable to boot from gpt partitions. except on EFI machines (Itanium and Intel Macs), but it is possible to combine GPT with an MBR such that you get a bootable partition (if nothing else, GEOM allows you to stick a GPT in a partition or slice) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
On Fri, Jul 28, 2006 at 03:36:27PM -0700, Matthew Dillon wrote: :On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: : On Thu, Jul 27, 2006 at 08:39:37AM +0200, Andreas Klemm wrote: : :Hmm, for the sake of compatibility, wouldn't it have been an option, :to add this extra bit to the end of the struct ? : Andreas /// The thing to note here is that FreeBSD had to make room for the UFS1+UFS2 boot code, so it moved the boot code back to the point where it abuts the 8-partition-sized disklabel. So at least insofar as FreeBSD goes, the partition table cannot be expanded to 16 partitions with UFS1+UFS2 boot code. I'm guessing that it *could* be expanded to 16 partitions with UFS1 only or UFS2 only boot code (assuming the boot code were relocated back to where it was originally in FreeBSD-4/5 times, before UFS2 came along). With regards to simply recognizing a DragonFly partition... yes, that would be easy to do. Since FreeBSD is now devfs-based, the bit we had to steal to support 16 partitions in /dev isn't an issue. Couldn't all BSDs restructure the disklabel in -current so that we would have the same base for the next major release ? Then its only a question of drivers to suppot UFS2 or not. But then compatibility would be there for some time ... Incompatible to UFS's like from Sun I think we are already, so we don't have to honour them. Remember a current thread in german BSD group where somebody complained about FreeBSD - mounting a Sun filesystem r/w - destroyed the filesystem. Luckily he could recover using fsck -b 32. Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? - http://www.apsfilter.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
* Matthew Dillon ([EMAIL PROTECTED]) wrote: felt that 8 partitions is restrictive. My main home server has 10 and the main DragonFly box has 11. There is another solution for FreeBSD folks, however. You *DO* have four slices to play with. You can put a disklabel with 8 partitions in it on each one (for 32 total). It isn't as convenient, but it does work. About `lack' of partitions - don't forget that labels can be nested. Just do `bsdlabel -w /dev/ad0s1e` - you'll get /dev/ad0s1ea. -- Best regards, Dmitry mailto:[EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 05:34:23PM -0400 I heard the voice of John Baldwin, and lo! it spake thus: On Thursday 27 July 2006 16:58, Mike Meyer wrote: Right. I typically install / and /usr as distinct files systems for just that reason (/ and /usr have different backup recovery strategies and I use dump, so that's why they are two partitions). So why does / need to be different from /var, /usr different from /usr/X11R6 and /home different from /usr/local? Seriously now - what I just described is my typical install. In my case I still have /home in /usr/home, but I should start making it separate in the hope that I could mount /usr read-only most of the time reducing the time it takes to fsck when I crash my test machines. I have / and /usr [sometimes one partition] mounted read-only on many of my systems. I like the peace of mind of KNOWING nothing'll go wonky on 'em on a crash, I like the shorter fsck times, I kinda like knowing there's that extra (very thin, but still extant) layer of protection against a lot of automated attacks... And, darnit, it just feels cleaner. I tend to have separate /var, /tmp, /home, and /usr/local which are kept rw since they have live and constantly-fiddled data on them, but everything else generally ends up ro since I only need to write them at specific discrete times. Out of the 11 partitions (multiple disks) on my workstation, only those 4 are generally rw. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 09:33:41PM -0400, Mike Meyer wrote: Small disk drive means smaller than any drive I can buy at the local Best Buy/Circuit City/CompUSA/similar. At the time, I needed an 80GB drive, and paid about $60 for it. Well then your comparison isn't really fair.. Sure, a brand new hard drive from a retail outlet is more expensive than a 10-year-old box (especially if the box is refurbished). No surprise there! I thought we were comparing oranges and oranges. In that case, check out www.geeks.com (the old computergeeks), they have a number of drives for sale under $49.95. Try http://www.pcretro.com/. Their current special is the Dell PowerEdge 6350 (dual CPU, 255MB ram, 2 9GB hot swap drives on separate controllers) for $49.95. The boxes I bought had a mouse and keyboard included, no monitor or speakers. Not that I cared - I tossed the mouse and keyboard on the spare parts pile and plugged them into a KVM. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
In [EMAIL PROTECTED], Rick C. Petty [EMAIL PROTECTED] typed: On Thu, Jul 27, 2006 at 09:33:41PM -0400, Mike Meyer wrote: Small disk drive means smaller than any drive I can buy at the local Best Buy/Circuit City/CompUSA/similar. At the time, I needed an 80GB drive, and paid about $60 for it. Well then your comparison isn't really fair.. Sure, a brand new hard drive from a retail outlet is more expensive than a 10-year-old box (especially if the box is refurbished). Um, I didn't buy the drive from a retail outlet. It was defined as small *because* it's to old and small for the retail outlets to carry it. Yes, it's not as old as the systems I bought, but it's the price point I had. I bought it through a price comparison engine; I'd have to dig through my records to find out who the actual seller was. No surprise there! I thought we were comparing oranges and oranges. In that case, check out www.geeks.com (the old computergeeks), they have a number of drives for sale under $49.95. The oranges we are comparing are acceptable solutions to wanting to isolate subsystems. The original solution was to buy modern disks, and put lots of partitions on them. My proposed solution is to buy a number of cheap boxes. A cheaper solution (the cheapest?) is to buy lots of small, cheap disks. (and before somebody brings it up, the costs involved only include the up-front cost.) They all have their tradeoffs, but the point I made is that objecting to my solution over the original one because of price doesn't carry that much weight. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
:On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: : On Thu, Jul 27, 2006 at 08:39:37AM +0200, Andreas Klemm wrote: : Later I wanted to mount the dfly filesystems on FreeBSD 6.1, : of course still my main Unix ;-) But it wasn't possible. : : DragonFly disklabels allow 16 entries by default, FreeBSD still limits : it to 8. That's why you can't read it directly. : : :Hmm, for the sake of compatibility, wouldn't it have been an option, :to add this extra bit to the end of the struct ? : : Andreas /// : :-- :Andreas Klemm - Powered by FreeBSD 6 The thing to note here is that FreeBSD had to make room for the UFS1+UFS2 boot code, so it moved the boot code back to the point where it abuts the 8-partition-sized disklabel. So at least insofar as FreeBSD goes, the partition table cannot be expanded to 16 partitions with UFS1+UFS2 boot code. I'm guessing that it *could* be expanded to 16 partitions with UFS1 only or UFS2 only boot code (assuming the boot code were relocated back to where it was originally in FreeBSD-4/5 times, before UFS2 came along). With regards to simply recognizing a DragonFly partition... yes, that would be easy to do. Since FreeBSD is now devfs-based, the bit we had to steal to support 16 partitions in /dev isn't an issue. I dunno if geom changes the equation any. Personally I have always felt that 8 partitions is restrictive. My main home server has 10 and the main DragonFly box has 11. There is another solution for FreeBSD folks, however. You *DO* have four slices to play with. You can put a disklabel with 8 partitions in it on each one (for 32 total). It isn't as convenient, but it does work. -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
In [EMAIL PROTECTED], Matthew Dillon [EMAIL PROTECTED] typed: There is another solution for FreeBSD folks, however. You *DO* have four slices to play with. You can put a disklabel with 8 partitions in it on each one (for 32 total). It isn't as convenient, but it does work. Um, that's many slices. The extended slice can hold as many slices as you want. The OS accessing them may have limits (I don't know if FreeBSD does or not). FreeBSD can put partitions in logical slices, but it can't boot from them. There are other options for those that want them. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
to followup myself ... I just see, we also have pack identifier, its the additional struct behind it that differs. Bootstrap name etc... Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? - http://www.apsfilter.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 08:39:37AM +0200, Andreas Klemm wrote: Later I wanted to mount the dfly filesystems on FreeBSD 6.1, of course still my main Unix ;-) But it wasn't possible. DragonFly disklabels allow 16 entries by default, FreeBSD still limits it to 8. That's why you can't read it directly. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: On Thu, Jul 27, 2006 at 08:39:37AM +0200, Andreas Klemm wrote: Later I wanted to mount the dfly filesystems on FreeBSD 6.1, of course still my main Unix ;-) But it wasn't possible. DragonFly disklabels allow 16 entries by default, FreeBSD still limits it to 8. That's why you can't read it directly. Are there plans to bump the default up from 8? I'm honestly torn on this topic whenever I install a new system. On the one hand I like having a lot of discrete mountpoints to control potential usage. On the other hand with drive space being so inexpensive I sometimes wonder if I need to bother and can get away with very few mountpoints. On very large disks (or arrays that appear as a single disk) I have to create multiple slices in order to get more than 8 mountpoints. Its an extra hoop to jump through. -steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: disklabel differences FreeBSD, DragonFly
to followup myself ... I just see, we also have pack identifier, its the additional struct behind it that differs. Bootstrap name etc... Those are parts of an union, so the total size still shouldn't change. I'd guess that the char[] format is used on-disk and the pointers are used in-memory. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 09:49:48AM -0400, Steve Ames wrote: On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: On Thu, Jul 27, 2006 at 08:39:37AM +0200, Andreas Klemm wrote: Later I wanted to mount the dfly filesystems on FreeBSD 6.1, of course still my main Unix ;-) But it wasn't possible. DragonFly disklabels allow 16 entries by default, FreeBSD still limits it to 8. That's why you can't read it directly. Are there plans to bump the default up from 8? I'm honestly torn on this topic whenever I install a new system. On the one hand I like having a lot of discrete mountpoints to control potential usage. On the other hand with drive space being so inexpensive I sometimes wonder if I need to bother and can get away with very few mountpoints. On very large disks (or arrays that appear as a single disk) I have to create multiple slices in order to get more than 8 mountpoints. Its an extra hoop to jump through. In most respects it's a pointless change since it just increases the cound from one small number to another one. If you need lots of partitions, gpt is your friend. The only problem with it at this point is that we haven't done the work to boot from it and thus do away with bsdlabels entierly. -- Brooks pgp553vxyVHKB.pgp Description: PGP signature
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 09:49:48AM -0400, Steve Ames wrote: On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: DragonFly disklabels allow 16 entries by default, FreeBSD still limits it to 8. That's why you can't read it directly. Are there plans to bump the default up from 8? I'm honestly torn on this topic whenever I install a new system. On the one hand I like having a lot of discrete mountpoints to control potential usage. On the other hand with drive space being so inexpensive I sometimes wonder if I need to bother and can get away with very few mountpoints. I would think that cheap disk space would mean larger disks which implies more mountpoints ??? On very large disks (or arrays that appear as a single disk) I have to create multiple slices in order to get more than 8 mountpoints. Its an extra hoop to jump through. Use gpt on non boot-disks, or use gvinum if you have lots of storage and like the inherent advantage of named labels, striping, and redundancy. I wasn't very happy with gpt or bsdlabel recently because you aren't allowed to modify the partitions if the gpt/bsdlabel is in use (i.e. one of the other partitions is currently mounted as a filesystem). I hope the GEOM people are working to improve this. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
In [EMAIL PROTECTED], Rick C. Petty [EMAIL PROTECTED] typed: On Thu, Jul 27, 2006 at 09:49:48AM -0400, Steve Ames wrote: On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: DragonFly disklabels allow 16 entries by default, FreeBSD still limits it to 8. That's why you can't read it directly. Are there plans to bump the default up from 8? I'm honestly torn on this topic whenever I install a new system. On the one hand I like having a lot of discrete mountpoints to control potential usage. On the other hand with drive space being so inexpensive I sometimes wonder if I need to bother and can get away with very few mountpoints. I would think that cheap disk space would mean larger disks which implies more mountpoints ??? Nope. One of the historical uses of partitions was to act as firewalls between subsystems, so that subsystem A running out of space didn't cause subsystem B to die for lack of space. This had the downside of making it more likely that one of the two would run out of space because the excess space from another subsystem could only be used by it. With cheap disk space, you overallocate by enough to give you plenty of warning before you have to deal with the issue. You can safely share that space, and doing so means you have to deal with the issue less often. These days, the only technical reason I know of for having separate mountpoints is because you want to run commands that work on filesystems on the two parts with different arguments or under different conditions. I wasn't very happy with gpt or bsdlabel recently because you aren't allowed to modify the partitions if the gpt/bsdlabel is in use (i.e. one of the other partitions is currently mounted as a filesystem). I hope the GEOM people are working to improve this. Yet another reason for having fewer partitions: you're less likely to want to modify them :-). mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
Mike Meyer wrote: In [EMAIL PROTECTED], Rick C. Petty [EMAIL PROTECTED] typed: On Thu, Jul 27, 2006 at 09:49:48AM -0400, Steve Ames wrote: On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: DragonFly disklabels allow 16 entries by default, FreeBSD still limits it to 8. That's why you can't read it directly. Are there plans to bump the default up from 8? I'm honestly torn on this topic whenever I install a new system. On the one hand I like having a lot of discrete mountpoints to control potential usage. On the other hand with drive space being so inexpensive I sometimes wonder if I need to bother and can get away with very few mountpoints. I would think that cheap disk space would mean larger disks which implies more mountpoints ??? Nope. One of the historical uses of partitions was to act as firewalls between subsystems, so that subsystem A running out of space didn't cause subsystem B to die for lack of space. This had the downside of making it more likely that one of the two would run out of space because the excess space from another subsystem could only be used by it. With cheap disk space, you overallocate by enough to give you plenty of warning before you have to deal with the issue. You can safely share that space, and doing so means you have to deal with the issue less often. 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. Fill /tmp or /var and many things can fail. Fill /home and it's just users who suffer a little but mail, demons etc. just carry on. 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. In some environments, fewer partitions may indeed be the new norm, but in others it would not. Personally, I would like a limit of 16. It would mean that I could fit all my regular partitions inside a single slice, freeing up other slices for, for example, experimenting with 64-bit, or -current, or whatever. Bootable FreeBSD slices will be stuck at 4 for the foreseeable future - extending the number of partitions within a slice frees up slices, which are the really limited resource. I have no real idea how hard it would be to extend from 8 to 16, but if the effort required were reasonably low, then it would get my vote. --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 02:28:18PM -0400, Mike Meyer wrote: In [EMAIL PROTECTED], Rick C. Petty [EMAIL PROTECTED] typed: On Thu, Jul 27, 2006 at 09:49:48AM -0400, Steve Ames wrote: On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: DragonFly disklabels allow 16 entries by default, FreeBSD still limits it to 8. That's why you can't read it directly. Are there plans to bump the default up from 8? I'm honestly torn on this topic whenever I install a new system. On the one hand I like having a lot of discrete mountpoints to control potential usage. On the other hand with drive space being so inexpensive I sometimes wonder if I need to bother and can get away with very few mountpoints. I would think that cheap disk space would mean larger disks which implies more mountpoints ??? Nope. One of the historical uses of partitions was to act as firewalls between subsystems, so that subsystem A running out of space didn't cause subsystem B to die for lack of space. This had the downside of making it more likely that one of the two would run out of space because the excess space from another subsystem could only be used by it. With cheap disk space, you overallocate by enough to give you plenty of warning before you have to deal with the issue. You can safely share that space, and doing so means you have to deal with the issue less often. These days, the only technical reason I know of for having separate mountpoints is because you want to run commands that work on filesystems on the two parts with different arguments or under different conditions. Well I still prefer to design my filesystems no matter how big disks are. So I have better control of what needs backup using dump and when I need to restore parts of my disk its also quicker and more reliable to restore a subtree. Also I'd gues that its still valid that less file movement in root filesystem increases robustness if you have a power outage. Same true for other important filesystems. Also it makes it easier to upgrade a system, since you only nail / and /usr, if the rest is in other filesystems. Also its easier to newfs / and /usr, if /var, /usr/local and /usr/X11R6, /home, ... are on differnet filesystems. Also you can increase system performance by choosing bigger block and frag size in filesystems with bigger files on average. If you have a news filesystem you perhaps want to finetune settings of filesystem to have more inodes available ... You see, I think there is still demand for using many filesystems if you are open minded for having the best support in every shitty situation ;-) Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? - http://www.apsfilter.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: On Thu, Jul 27, 2006 at 08:39:37AM +0200, Andreas Klemm wrote: Later I wanted to mount the dfly filesystems on FreeBSD 6.1, of course still my main Unix ;-) But it wasn't possible. DragonFly disklabels allow 16 entries by default, FreeBSD still limits it to 8. That's why you can't read it directly. Hmm, for the sake of compatibility, wouldn't it have been an option, to add this extra bit to the end of the struct ? Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? - http://www.apsfilter.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
In [EMAIL PROTECTED], Michael R. Wayne [EMAIL PROTECTED] typed: On Thu, Jul 27, 2006 at 02:28:18PM -0400, Mike Meyer wrote: These days, the only technical reason I know of for having separate mountpoints is because you want to run commands that work on filesystems on the two parts with different arguments or under different conditions. Or you want to run a bunch of jails. You don't need mount points to run jails. In fact, the man page (on 5.5, anyway) provides examples that *break* if you put the jails on a separate mount point. Or you want to give a bunch of users a big chunk of space and quotas are a bad fit. That's a social reason, not a technical one. That used to be really common as well, but these days a bunch of users tend to get their own machine. In [EMAIL PROTECTED], Alex Zbyslaw [EMAIL PROTECTED] typed: Mike Meyer wrote: In [EMAIL PROTECTED], Rick C. Petty [EMAIL PROTECTED] typed: On Thu, Jul 27, 2006 at 09:49:48AM -0400, Steve Ames wrote: On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: DragonFly disklabels allow 16 entries by default, FreeBSD still limits it to 8. That's why you can't read it directly. Are there plans to bump the default up from 8? I'm honestly torn on this topic whenever I install a new system. On the one hand I like having a lot of discrete mountpoints to control potential usage. On the other hand with drive space being so inexpensive I sometimes wonder if I need to bother and can get away with very few mountpoints. I would think that cheap disk space would mean larger disks which implies more mountpoints ??? Nope. One of the historical uses of partitions was to act as firewalls between subsystems, so that subsystem A running out of space didn't cause subsystem B to die for lack of space. This had the downside of making it more likely that one of the two would run out of space because the excess space from another subsystem could only be used by it. With cheap disk space, you overallocate by enough to give you plenty of warning before you have to deal with the issue. You can safely share that space, and doing so means you have to deal with the issue less often. 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. A typical installation will have smaller, slower disks. A high-end installation with faster disks will almost certainly have lots more space as well. So it's perfectly reasonable to rely on disks to not fill up in a matter of minutes. In practice, log files are several orders of magnitude smaller than the actual data dealt with by most application. A few hundred megabytes is more than adequate log space for most systems, with runaway processes filling them in a day or so. So I give those systems a gigabyte of log space, 'cause disk is *cheap*. And yes, I separate /var from /home and /usr, but not because I'm worried about them running out of space. Fill /tmp or /var and many things can fail. Fill /home and it's just users who suffer a little but mail, demons etc. just carry on. You're being inconsistent. Log files normally go on /var, so if you fill that, your demons may well fail, depending on how they react to not being able to log messages. On the other hand, for some demons it makes sense to treat their data just like any other user data, so they'd be on /home, and suddenly they're failing when /home fills up. I had a system fall over for lack of disk space this month. It was an old system, that only had 16GB of disk for file storage, and the 300GB drive upgrade had already been ordered. It's a four-core 3GHz opteron system, doing ETL processing as fast as it's little chips can cycle. It took *five hours* to fill up when half of the data started collecting on it instead of being loaded into the database. If it had had the disk upgrade, it would have take a couple of days. 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. In some environments,
Re: disklabel differences FreeBSD, DragonFly
In [EMAIL PROTECTED], Andreas Klemm [EMAIL PROTECTED] typed: On Thu, Jul 27, 2006 at 02:28:18PM -0400, Mike Meyer wrote: These days, the only technical reason I know of for having separate mountpoints is because you want to run commands that work on filesystems on the two parts with different arguments or under different conditions. Well I still prefer to design my filesystems no matter how big disks are. Yes, and most of those qualify as needing to run commands that workon filesystems on the two parts with different arguments Also I'd gues that its still valid that less file movement in root filesystem increases robustness if you have a power outage. Same true for other important filesystems. Actually, it one of the FS gurus convincing me that this was no longer true that converted me to the idea that reducing the file system count was a good idea. What you say was certainly true for 4.2BSD, but when was the last time you saw an entire file system toasted when something failed hard? Or even significant damage to files that weren't actually in transit at the time? I know the last time it happened to me - it was over a decade ago. I had a desktop Solaris box I'd set up as web server because the IT department was a typical IT department. So it wasn't on batteries like every other server in the place. We took a power hit, and it crashed hard. Power came back, and it started fsck'ing it's file system. Partway through that we got a *second* power hit, so it crashed hard in the middle of fsck'ing. This power outage lasted long enough that the backup generators kicked in, so it came back up and started fsck'ing again. At which piont the backup generators cut out, because they hadn't been refueled after the last outage. So it crashed hard *again* in the middle of fsck'ing the file system. The file system was unrecoverable. Also it makes it easier to upgrade a system, since you only nail / and /usr, if the rest is in other filesystems. Also its easier to newfs / and /usr, if /var, /usr/local and /usr/X11R6, /home, ... are on differnet filesystems. Right. I typically install / and /usr as distinct files systems for just that reason (/ and /usr have different backup recovery strategies and I use dump, so that's why they are two partitions). So why does / need to be different from /var, /usr different from /usr/X11R6 and /home different from /usr/local? Seriously now - what I just described is my typical install. You see, I think there is still demand for using many filesystems if you are open minded for having the best support in every shitty situation ;-) 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. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 10:25:28PM +0200, Andreas Klemm wrote: On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: On Thu, Jul 27, 2006 at 08:39:37AM +0200, Andreas Klemm wrote: Later I wanted to mount the dfly filesystems on FreeBSD 6.1, of course still my main Unix ;-) But it wasn't possible. DragonFly disklabels allow 16 entries by default, FreeBSD still limits it to 8. That's why you can't read it directly. Hmm, for the sake of compatibility, wouldn't it have been an option, to add this extra bit to the end of the struct ? The layout of the struct has not changed. FreeBSD simply rejects the disk label because the number of entries is too large. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
On Thursday 27 July 2006 16:58, Mike Meyer wrote:
Right. I typically install / and /usr as distinct files systems for
just that reason (/ and /usr have different backup recovery
strategies and I use dump, so that's why they are two partitions). So
why does / need to be different from /var, /usr different from
/usr/X11R6 and /home different from /usr/local? Seriously now - what I
just described is my typical install.
In my case I still have /home in /usr/home, but I should start making it
separate in the hope that I could mount /usr read-only most of the time
reducing the time it takes to fsck when I crash my test machines. This is
peculiar to an environ where one expects to crash a lot though. :) Even so,
I would be looking at /, /usr, /var, /tmp, /home, and swap. Still under 7
('c' is reserved).
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
In [EMAIL PROTECTED], Alex Zbyslaw [EMAIL PROTECTED] 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
Re: disklabel differences FreeBSD, DragonFly
Mike Meyer wrote: 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. I have no real idea what this means, sorry. It seems to me that whoever made the initial decision to stop at 8 (size of an integer?) clearly thought counting past 2 was worthwhile. Maybe the original reasons no longer apply since quite a lot has changed since then :-) 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 don't understand this either. Surely the box has to include the disk space so how can it cost less? If it costs less because it's a cheap piece of junk, why would I even want it? And the cost of the system doesn't stop at the up front price - running costs including maintaining the box surely count (not to mention that I have nowhere to put the damn thing). And I'm not sure where needing a separate partition and criticality became the same thing. I don't claim to want or need separate partitions because any particular subset of the filesystem is critical, but because I want it to be separate for at least the two reasons outlined below. 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. Except that we also have the dump, and the different params for different parts of the filesystem arguments. I think you agreed that you counted those as technical reasons. 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 Fine. You have access to lots of money and infrastructure. I don't. Throwing money at a problem is not a solution available to everyone. 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
Re: disklabel differences FreeBSD, DragonFly
Mike Meyer wrote: 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'm not sure how that's even possible. A quick glance at newegg.com: $17.99 (+$6.13) [recertified] socket A motherboard $39.99 [oem] AMD Duron socket A processor $13.99 (+$4.99) 128MB RAM === $71.97 (+$11.12 shipping) = $83.09. This is assuming you have an extra case, power supply, and video card to throw in it. What do you consider a small disk drive? Newegg has a 40G for $39.99 + $5.64 shipping. Yeah, so small disk drives seem to be half the price of the cheapest possible box. Feel free to enlighten me, I'd love to know where you shop that has a system under US$50 ! -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
In [EMAIL PROTECTED], Rick C. Petty [EMAIL PROTECTED] typed: Mike Meyer wrote: 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'm not sure how that's even possible. A quick glance at newegg.com: $17.99 (+$6.13) [recertified] socket A motherboard $39.99[oem] AMD Duron socket A processor $13.99 (+$4.99) 128MB RAM === $71.97 (+$11.12 shipping) = $83.09. This is assuming you have an extra case, power supply, and video card to throw in it. What do you consider a small disk drive? Newegg has a 40G for $39.99 + $5.64 shipping. Yeah, so small disk drives seem to be half the price of the cheapest possible box. Feel free to enlighten me, I'd love to know where you shop that has a system under US$50 ! Small disk drive means smaller than any drive I can buy at the local Best Buy/Circuit City/CompUSA/similar. At the time, I needed an 80GB drive, and paid about $60 for it. Try http://www.pcretro.com/. Their current special is the Dell PowerEdge 6350 (dual CPU, 255MB ram, 2 9GB hot swap drives on separate controllers) for $49.95. The boxes I bought had a mouse and keyboard included, no monitor or speakers. Not that I cared - I tossed the mouse and keyboard on the spare parts pile and plugged them into a KVM. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
