Re: a couple of things I dislike about BSD
On Jul 22, 2012 5:42 PM, "Pierre Abbat" wrote: > > 1. When I run bc, I frequently edit the previous line and make a change: > 15/56 > .26785714285714285714 > a(15/56) > .26171350240120506395 > a(15/56)*45/a(1) > 14.99507912917598589467 > In Linux, I hit uparrow and edit the line. In DFBSD, I have to type the whole > line again. This is, I'm sure, a license issue; the readline library in DFly > is GNU readline. The bugs section says "It’s too big and too slow," so why > not write a BSD version that's smaller and faster? > (The calculation relates to the upper slope of my future house's roof.) There is one already. It's called libedit. Don't know what the status is in DFlyBSD, but it's basically replaced readline in FreeBSD. > 2. less in Linux saves the screen when it starts and restores it when it ends. > In DFly it doesn't; it leaves a screenful of the file visible when it exits. > This isn't that big a deal, except when I'm looking at my PIN or password > file, which I do with less, not cat, so that it won't be left on my screen. > Not that it really matters, since I'm alone, but to some people it may. This is something I absolutely hate about Linux distros. Makes reading man pages a royal pain, as the page disappears instead of remaining onscreen where you can read it while running commands. As such, I add PAGER='less -X' to all my Linux boxes to get the BSD behaviour. Read the man page for less to see which flag to set in which env variable to make less work the way you want.
Re: nice: Badly formed number
On Tue, Dec 6, 2011 at 1:16 PM, william opensource4you < william.o...@gmail.com> wrote: > Am I the only one having troubles with the command nice ? > I'm running: DragonFly mydfbsd 2.10-RELEASE DragonFly > v2.10.1.1.gf7ba0-RELEASE #1: Mon Apr 25 19:51:42 UTC 2011 > r...@pkgbox32.dragonflybsd.org:/usr/obj/usr/src/sys/GENERIC_SMP i386 > > Here the results (the last example is coming from the man page): > mydfbsd# nice -5 date > Tue Dec 6 22:11:19 CET 2011 > mydfbsd# nice -n5 date > nice: Badly formed number. > mydfbsd# nice -n 5 date > nice: Badly formed number. > nice is both a binary (/usr/bin/nice) and a shell built-in function. Depending on the shell you are using, you will either be using the built-in or the binary. And the syntax for them is very different. I believe you are using the csh above, thus using the built-in nice, which does not support -n. > If I take the source code on the gitweb: > http://gitweb.dragonflybsd.org/dragonfly.git/blob/HEAD:/usr.bin/nice/nice.c > I compile it by doing "gcc nice.c" > > here the results: > > mydfbsd# ./a.out -5 date > Tue Dec 6 22:11:08 CET 2011 > mydfbsd# ./a.out -n5 date > Tue Dec 6 22:11:11 CET 2011 > mydfbsd# ./a.out -n 5 date > Tue Dec 6 22:11:14 CET 2011 > Here you are giving the full path to the nice binary, so you are always using that binary. Try the above using /usr/bin/nice for each test, and you'll get the same results. Read the man page for your shell to see if nice is a built-in function or not. -- Freddie Cash fjwc...@gmail.com
Re: Can DFly mount ext4?
At the grub prompt hit esc to get the grub menu. Then press the e key to edit the first entry. Add a 1 to the end of the line. Press enter to save the line then press b to boot. That will drop you into run-level 1 aka single user mode, with root access. You should be able to fix things from there. Sent from my iPod On 2011-06-26, at 5:44 PM, Pierre Abbat wrote: > A friend gave me an Ubuntu laptop which I proceeded to install a few programs > on and then hose. It came with a user "a" which I decided to change > to "phma". I renamed the home directory, edited /etc/passwd and /etc/group, > and rebooted. I had forgotten to edit /etc/shadow, so I can't log in. It's > set up to show "Ubuntu" and four dots instead of a GRUB prompt. I tried > mounting it in the USB enclosure on my Linux box; it said "unsupported > features", which a bit of googling tells me means it's an ext4 filesystem. I > try mounting it on DragonFly as ext2fs and get "invalid argument". Is there a > way to mount ext4fs? > > Pierre > -- > sei do'anai mi'a djuno puze'e noroi nalselganse srera
Re: Filesystems
On Sat, Apr 23, 2011 at 3:43 AM, Tomas Bodzar wrote: > 3) FreeBSD probably best port outside of Solaris, but main porter > died (sad) and he was great regarding internals so it's quite harder > now for them The main porter of ZFS to FreeBSD is Pawel Jakub Dawidek (probably spelt a bit wrong) aka p...@freebsd.org, who is most certainly still alive, and continuing work on ZFS, HAST, GEOM_GATE, and other interesting storage stuff. -- Freddie Cash fjwc...@gmail.com
Re: Setting terminal in single user mode
On Thu, Jan 6, 2011 at 9:11 AM, Francisco Reyes wrote: > Pierre Abbat writes: > ee is also an editor in DragonFly, but it's in /usr/bin, whereas mined is >> in /bin, so it can be used when /usr isn't mounted. > > Hmm.. Why not have ee in /bin then? > I am just thinking that one set of likely users to try/use DragonFlyBSD will > be FreeBSD users. I think many (most?) new users coming from FreeBSD will > not know about mined. Is mined used by other BSDs? FreeBSD has mined in the ports tree: editors/mined ee is also installed under /usr/bin on FreeBSD, leaving just /bin/vi and /rescue/vi for single-user mode (if /usr is a separate filesystem). -- Freddie Cash fjwc...@gmail.com
Re: ctrl alt backspace does not exit X server
On Fri, Nov 5, 2010 at 5:37 PM, Sdävtaker wrote: > X.org removed that feature few versions ago, if you want to have the > ability to use it again need to start it with "-retro". Or, you can add the following to your xorg.conf: Section "ServerFlags" Option "DontVTSwitch" "False" Option "DontZap" "False" EndSection The first allows you to use CTRL+ALT+Function keys to switch between the console and X. The second allows you to use CTRL+ALT+Backspace to kill the X server. -- Freddie Cash fjwc...@gmail.com
Re: HEADS UP: BIND Removal. Short instructions for migration to pkgsrc-BIND
On Thu, May 6, 2010 at 11:01 AM, Chris Turner wrote: > Sascha Wildner wrote: > >> The only question is: Do we want to _maintain_ a drill and libldns in our >> base from now on? Because that's what we would have to do if it's in base. >> > > there needs to be some way to verify DNS out of the box. period. without > pkgsrc. period. this is non optional, IMHO. > > otherwise I might as well port System-III unix and start UUCPing my email > with a 300bps acoustic coupler.. > > kernel!dragonfly!ucbvax anyone? > If you just need to verify that DNS works (resolve hostname to IP), then what's wrong with "ping some.host.com"? ;) Kills two birds with one stone: DNS lookups work, and Internet connection is live (if using a hostname on the Internet). No need for host, dig, nslookup, etc. ;) -- Freddie Cash fjwc...@gmail.com
Re: enabling RGB output
On Mon, Feb 15, 2010 at 9:25 PM, Pierre Abbat wrote: > Last Saturday I brought my laptop to church to show someone the DVD (it's > about Bible translation and two people had tried to play it on their > Windows > boxen without success - I'm going to ask them to try VLC). I put the laptop > on the table and he pulled a sound cable and a video cable and plugged them > into the laptop. The sound immediately came out of the room's speakers. He > then tried pressing function keys to get the video to come out, but nothing > happened. How can I tell the laptop to output to the video connector? > The simplest method is to plug in the external monitor while the laptop is off. Some laptop BIOSes will auto-configure the ports based on what's detected at startup. Some will enable/disable the external ports via a Fn (blue function key near the left Control key) key combo (usually Fn+F5), but that doesn't always work with X11. If X11 is configured correctly, and RandR 1.2 support shows as enabled in /var/log/Xorg.0.log, then you can use either the CLI xrandr tool or a GUI version like krandr (for KDE) to configure all the screens. However, this will only work if X detects the external port at startup, which usually requires the cable be plugged in before X starts. -- Freddie Cash fjwc...@gmail.com
Re: SAS RAID controllers support
On Mon, Feb 1, 2010 at 4:41 AM, Francois Tigeot wrote: > On Mon, Feb 01, 2010 at 12:02:38PM +0100, Francois Tigeot wrote: > > > > I'm curious about the state of hardware RAID controllers in DragonFly. > > > > Would a LSI1068-E controller be usable with DragonFly-2.4 ? > > This page answers my question for this controller: > > > http://blogaristoo.lqx.net/index.php/2009/01/14/sassy-lip-from-the-lsi-1068e > > LSI1068e is *not* usable at all. > You'd be better off going with separate PCI-X/PCIe controllers. Not sure about DragonFlyBSD, but FreeBSD fully supports these cards (mpt(4), mfi(4), twa(4)): 4-port PCI-X: LSI SAS 3041X-R 8-port PCI-X: LSI SAS 3080X-R 4-port PCIe: LSI SAS 3041E-R 8-port PCIe: LSI SAS 3081E-R There's also the 3Ware cards (these are SAS and SATA): 4-port PCIe: LSI 3Ware 9690SA-4I 8-port PCIe: LSI 3Ware 9690SA-8I These are SATA, but include support for mini-SAS connectors and do work with SAS drives: 4-port PCIe: LSI 3Ware 9650SE-4LPML 8-port PCIe: LSI 3Ware 9650SE-8LPML 4-port PCI-X: LSI 3Ware 9550SXU-4LP 8-port PCI-X: LSI 3Ware 9550SXU-8LP -- Freddie Cash fjwc...@gmail.com
Re: nextboot(8)
On Thu, Nov 19, 2009 at 4:29 AM, Francis GUDIN wrote: > Three quick questions regarding nextboot(8): > - by default, fdisk(8) uses /boot/mbr and boot0cfg(8) uses /boot/boot0 > (which differ, cmp tells me). Which one should be installed to enjoy > nextboot(8) ? > - does nextboot(8) handle the 'serno' enhancements ? just in case the > manpage lags a bit behind actual functionality… > - almost off-topic, but the knowledgeable people here might save my > time: would another slice (Linux) be still bootable after nextboot(8) > configuration, given that for now the host uses GRUB ? anyone kind > enough to give pointers as to which file to include in nextboot's > bootstring for that Linux slice ? > > The idea is to have two OS+pkg slices: one production config + an > alternative one to lower risks on upgrades (à la «Linux from scratch»). > The server is remote, and I don't have any KVM, so disasters would be > painful to recover from… > > Unless things have vastly diverged in the way DFly boots compared to FBSD, nextboot doesn't have anything to do with which partitions are booted from. All it does is tell the loader which kernel to use. Mainly used for testing a kernel, since a reboot will load the normal kernel. Have a look at boot.config(5), which is a file that you can use to tell the loader and the kernel which partition to use as the root filesystem. Or, look into using a boot manager. DFly comes with a simple one that will list each bootable partition. Or you can install a simple one like GAG. Or you can use GRUB, since you already have it installed on the Linux partition. -- Freddie Cash fjwc...@gmail.com
Re: Hammer or ZFS based backup, encryption
On Sun, Feb 22, 2009 at 11:10 PM, Bill Hacker wrote: > Freddie Cash wrote: >> On Sat, Feb 21, 2009 at 10:39 AM, Csaba Henk wrote: >>> I need to setup a backup machine, and I intend to utilize today's >>> snapshotty filesystems (which boils down to Dfly+Hammer or FBSD+ZFS -- >>> btrfs is not there yet, and I don't feel like dwelving into Solaris). >>> Set up such an OS with such an fs, and backup by syncing to the >>> snapshotty fs and create a snapshot. >>> >>> I wonder about the following things: >>> >>> 1) Any idea how does this approach scale related to more conventional >>> solutions, >>> like rdiff-backup or dump(8)? I see the the pros, but are there any >>> cons? How effective is taking regular snapshots space-wise? >>> >>> 2) Is there any practical argument for choosing between Dfly+Hammer and >>> FBSD+ZFS? (Feel free to give biased answers :) ) >>> >>> 3) I'd like to encrypt stuff, either at device or fs level. For >>> FreeBSD there is geli(8). I haven't found anything for DragonFly. >>> Is there any way to get at it on DragonFly? >> >> We do this at work, using FreeBSD 7.1 and ZFS, for backing up over 80 >> remote Linux and FreeBSD servers, and 1 Windows station. We have two >> servers, one that does the backups every night, and another that >> mirrors the backups during the day. > > *trimmed* (description of a quite decent ZFS approach) > >> >> After the initial rsync of a server, which can take several days as it >> can easily max out an ADSL link's upload bandwidth, the daily run >> takes about 6 hours, most of which is waiting for rsync to generate >> the file listing. >> > > *snipped* > > But there we are, Startup 'seeding; is unavidable, but thereafter ... among > other things, looking to reduce the reliance on rsync (and similar CVS'ish > or git'ish techniques) having to 'inventory' stuff at a high per-file level > that a 'hammer mirror-stream' (or GMIRROR to networked RAID) could do 'as > you go along' at a lower level - closer to the actual blocks as they are > being written. > > How, and how well, would ZFS handle redundant pools on separate sites? > > And can that be a streaming process - even if that means the redundancy > target is r/o for 'the duration', as a hammer slave would be? ZFS includes "snapshot send" and "snapshot recv" commands for streaming snapshots across the network. However, there is currently a bottleneck in the recv code that prevents it from saturating even a 100 Mbit link. This affects ZFS v6 which is in FreeBSD 7.x, and I'm fairly certain that it hasn't been fixed in ZFS v13 which is in FreeBSD 8. Once that has been fixed, then it can be used for near-real-time streaming of snapshots across the network. Until then, you can rsync snapshots from the master to the slave server(s), which is what we're doing. -- Freddie Cash fjwc...@gmail.com
Re: OT - was Hammer or ZFS based backup, encryption
On Mon, Feb 23, 2009 at 8:44 AM, Jeremy Chadwick wrote: > On Mon, Feb 23, 2009 at 05:19:14PM +0100, Jasse Jansson wrote: >> On Feb 23, 2009, at 11:54 AM, Bill Hacker wrote: >>> Robert Luciani wrote: >>>> Freddie Cash wrote: >>>>> Booting FreeBSD 7.1 into a full KDE 4.2 >>>>> desktop takes less than 5 minutes. This is using 3x 120 GB SATA >>>>> drives in a single raidz1. >>>> Wow 5 minutes?! >>>> I don't think I'd be pushing it if I said that seems really slow. :S >>>> On such a fast machine I'd be irritated if it took over a minute to >>>> boot. On my >>>> 3Ghz Athlon X2 w/ 2Gb RAM, DragonFly boots vkernels, hosting >>>> services, and Gnome >>>> in about a minute with my two 500Gb hammer drives. >>> >>> One minute 45 seconds into Xfce4 for a VIA C7 @ 1.5 GHz, 2 GB DDR-533, >>> all-hammerfs on 2 natacontrol RAID1 'antique' 60 GB PATA UDMA 100 HDD. >>> >>> One minute 4 seconds into Xfce4 for an Intel T2130 @ 1.86 GHz 2 GB ? >>> RAM, 1 X 120 GB 2.5" HDD, DFLY on 33 GB ad0s1, UFS2 with one hammer >>> partition. >>> >>> RIADz looks to be the wall-time hog >> >> RAIDZ is known to be slow, even the main developers admit it if you >> force them to it. > > I'd recommend the individual seeing ~5 minute boot times try disabling > ZFS prefetching. Place vfs.zfs.prefetch_disable="1" in > /boot/loader.conf and reboot the machine. Prefetch is disabled. The delays in the boot on this system are from using a USB stick for the / partition. From kernel load to desktop load is about 2 minutes. It takes about 2 minutes to get the kernel and modules loaded, though. However, my Debian Lenny station at work takes almost 5 minutes to get to a KDE 4.2 desktop, and that's using a single SATA harddrive with ext3 and xfs. Doesn't botther me, though, as I reboot maybe once per month, sometimes only once per quarter. I've never really understood the reasoning for 30-second boot times. -- Freddie Cash fjwc...@gmail.com
Re: OT - was Hammer or ZFS based backup, encryption
On Mon, Feb 23, 2009 at 2:35 AM, Robert Luciani wrote: > Freddie Cash wrote: >> Booting FreeBSD 7.1 into a full KDE 4.2 >> desktop takes less than 5 minutes. This is using 3x 120 GB SATA >> drives in a single raidz1. > > Wow 5 minutes?! > I don't think I'd be pushing it if I said that seems really slow. :S > On such a fast machine I'd be irritated if it took over a minute to boot. On > my > 3Ghz Athlon X2 w/ 2Gb RAM, DragonFly boots vkernels, hosting services, and > Gnome > in about a minute with my two 500Gb hammer drives. That includes the BIOS/POST delays to find the USB stick, a boot.config delay, the boot menu delay, loading the kernel off a USB stick delay, loading a bunch of kernel modules off the USB stick, the SCSI sub-system delay, starting a bunch of daemons including Samba, DHCPd, Apache, NFSd, and KDM, and then logging in. The time from the kernel being loaded to the desktop appearing is about 2 minutes. It just takes a long time to get to the point where the kernel is loaded. :) -- Freddie Cash fjwc...@gmail.com
Re: OT - was Hammer or ZFS based backup, encryption
On Sat, Feb 21, 2009 at 7:17 PM, Jeremy Chadwick wrote: > On Sun, Feb 22, 2009 at 11:59:57AM +1100, Dmitri Nikulin wrote: >> On Sun, Feb 22, 2009 at 10:34 AM, Bill Hacker wrote: >> > Hopefully more 'good stuff' will be ported out of Solaris before it hits >> > the >> > 'too costly vs the alternatives' wall and is orphaned. >> >> Btrfs has been merged into mainline Linux now, and although it's >> pretty far behind ZFS in completeness at the moment, it represents a >> far greater degree of flexibility and power. In a couple of years when >> it's stable and user friendly, high-end storage solutions will move >> back to Linux, after having given Sun a lot of contracts due >> specifically to ZFS. > > The fact that btrfs offers grow/shrink capability puts it ahead of ZFS > with regards to home users who desire a NAS. I can't stress this point > enough. ZFS's lack of this capability limits its scope. As it stands > now, if you replace a disk with a larger one, you have to go through > this extremely fun process to make use of the new space available: > > - Offload all of your data somewhere (read: not "zfs export"); rsync > is usually what people end up using -- if you have multiple ZFS > filesystems, this can take some time > - zpool destroy > - zpool create > - zfs create According to the ZFS Admin manual, doing an online "replace" of the drive with a larger one, than a zpool export and zpool import is all that's needed to make use of the extra space. In theory, one can replace all the drives in the storage array one at a time, allowing the resilvers to complete each time, and then just export/import once, and have a massively larger pool to use. > And if you add a new disk to the system, it's impossible to add that > disk to the existing pool -- you can, of course, create an entirely > new zpool which uses that disk, but that has nothing to do with the > existing zpool. So you get to do the above dance. You can add vdevs to a pool at any time. Data will be striped across all vdevs in the pool. What you can't do is extend a raidz vdev. But you can add more raidz vdevs to a pool. If you create a pool with a 3-drive raidz vdev, you can later extend the pool by adding another 3-drive raidz vdev. Or by adding a mirrored vdev. Or by just adding a single drive (although then you lose the redundancy of the entire pool). I've done this several times when playing around with ZFS on FreeBSD 7.1 on a test system with 24-drives. Started with a 12-drive raidz2 vdev. Then addded a 6-drive raidz2. Then another 6-drive raidz2. Then played around with 3x 8-drive raidz2 vdevs. And a bunch of other setups, just to see what the limitations were. The only one is that you can't start with an X-drive raidz2 and later extend that single raidz2 vdev out to Y-drives, like you can with some hardware RAID controllers. > I'll also point out that ZFS on FreeBSD (at least 7.x) performs very > differently than on Solaris 10. We use Solaris 10 x86 + ZFS at my > workplace, and the overall usability of the system during heavy disk I/O > is much more refined (read: smooth) than on FreeBSD. It's interesting > to do something like "zpool iostat 1" on FreeBSD compared to Solaris 10; > FreeBSD will show massive write bursts (e.g. 0MB, 0MB, 0MB, 70MB, 0MB, > 0MB, 0MB, 67MB, etc.), while Solaris behaves more appropriately (50MB, > 60MB, 70MB, 40MB, etc.). "zpool scrub" is a great way to test this. Hrm, we haven't run into that, but we're mostly limited by network speeds in our setup. "zpool iostat" shows a fairly constant 2 MB read or write to each of the 24-drives in the servers. But that's all rsync usage, and limited by the ADSL links we use. -- Freddie Cash fjwc...@gmail.com
Re: Hammer or ZFS based backup, encryption
On Sat, Feb 21, 2009 at 10:39 AM, Csaba Henk wrote: > I need to setup a backup machine, and I intend to utilize today's > snapshotty filesystems (which boils down to Dfly+Hammer or FBSD+ZFS -- > btrfs is not there yet, and I don't feel like dwelving into Solaris). > Set up such an OS with such an fs, and backup by syncing to the > snapshotty fs and create a snapshot. > > I wonder about the following things: > > 1) Any idea how does this approach scale related to more conventional > solutions, > like rdiff-backup or dump(8)? I see the the pros, but are there any > cons? How effective is taking regular snapshots space-wise? > > 2) Is there any practical argument for choosing between Dfly+Hammer and > FBSD+ZFS? (Feel free to give biased answers :) ) > > 3) I'd like to encrypt stuff, either at device or fs level. For > FreeBSD there is geli(8). I haven't found anything for DragonFly. > Is there any way to get at it on DragonFly? We do this at work, using FreeBSD 7.1 and ZFS, for backing up over 80 remote Linux and FreeBSD servers, and 1 Windows station. We have two servers, one that does the backups every night, and another that mirrors the backups during the day. The main backup server is: - Chenbro 5U rackmount case with 24 drive bays and hot-swappable SATA backplane - Tyan h2000M motherboard - 2x Opteron 2200-series CPUs @ 2.6 GHz (dual-core) - 8 GB ECC DDR2-667 SDRAM - 3Ware 9650SE PCIe RAID controller - 3Ware 9550SXU PCI-X RAID controller - 24x 500 GB SATA HDs (Seagate and Maxtor) - 1350W 4-way hot-swappable PSU All 24 drives are configured as "Single Disk" arrays, and show up as 24 separate SCSI devices in the OS. This allows the RAID controller to use the 256 MB of onboard RAM as another level of cache and allows us to use the 3dm2 management console (as opposed to JBOD-mode where it becomes just a dumb SATA controller). The main backup server has 2x 2GB CompactFlash in IDE adapters that house the base OS install. The second backup server has 2x 2GB USB sticks for the OS install. All space on all 24 drives is used for the ZFS pool. The main backup server has a single 24-drive raidz2 dataset. Not optimal, but we didn't know any better back then. :) The second server has 3x 8-drive raidz2 datasets. Not as much usable space, but better performance and redundancy. / and /usr are on the CF/USB. Having /usr on there makes single-user mode a lot nicer to use. /usr/local, /home, /usr/ports, /usr/ports/distfiles, /usr/src, /usr/obj, /var, /tmp, and /backups are ZFS filesystems with various properties set (like compression on /usr/src, /usr/ports, and /backups). We have a custom rsync script that does the backups of the remote servers everynight, and that creates a snapshot named after the date. And another custom script that does an rsync from a snapshot on the main server to the backups directory on the second server, and then creates a snapshot on there. After the initial rsync of a server, which can take several days as it can easily max out an ADSL link's upload bandwidth, the daily run takes about 6 hours, most of which is waiting for rsync to generate the file listing. This setup works wonders, and has been used to re-image servers, restore files from backups, and even re-set the permissions/ownerships for /home after a teacher did a "chown -R" on /home by mistake. Being able to cd into a snapshot directory and directly access the files is a god-send. We've been running this setup since August 2008. Disk usage so far is just over 6 TB. Daily snapshots average <10 GB. With ~10 TB of drive space in each server, we won't run out of space for a while yet. And when we get under 1 TB of free space, we just start swapping drives out for larger ones and the extra space is automatically added into the pool. Theoretically, we can put just under 50 TB of disk into these systems. :) For the curious, these boxes cost under $10,000 CDN. We like to mention that when the storage vendors call with their $50,000 US "budget" storage systems with 5 TB of disk space. :D They tend to not call back. -- Freddie Cash fjwc...@gmail.com
Re: OT - was Hammer or ZFS based backup, encryption
On Sun, Feb 22, 2009 at 7:50 AM, Bill Hacker wrote: > Side issue again - just brought up DFLY 2.3.0, default all-hammer layout. > > - atop a natacontrol RAID1 on a pair of salvaged 60 GB IBM 'Deathstars'. > - VIA C7 1.5 GHz CPU (the el-cheapo MB aimed at Wal-Mart) > - pulled half the RAM, leaving only 1GB > > Periodically, the aged IBM's sound like squirrels having a go in a gravel > pit, Xfce4 is *very* slow, but it hadn't started swapping, and based on what > 'top' is showing should actually work decently for basic file, web, or mail > serving, especially as the OpenSSL recognizes the VIA padlock engine. > Planty fast enough with 2GB, BTW. > > ZFS is not famed for tolerating that meagre a resource ration as well as > HAMMER ZFS on FreeBSD 7.1 runs well with 2 GB of RAM and a 2.6 GHz P4 CPU (32-bit). It just requires tuning of a couple of kernel tunables via loader.conf. It runs better with a 64-bit CPU and more RAM, but it is perfectly usable with 2 GB. Booting FreeBSD 7.1 into a full KDE 4.2 desktop takes less than 5 minutes. This is using 3x 120 GB SATA drives in a single raidz1. ZFS will try to use every bit of RAM that it can as a cache. But you can limit how much it can use. There are reports on the FreeBSD mailing lists of people using it on laptops (slow drives), and on systems with only 768 MB of RAM. -- Freddie Cash fjwc...@gmail.com
Re: OT - was Hammer or ZFS based backup, encryption
On Sun, Feb 22, 2009 at 6:33 AM, Jeremy Chadwick wrote:
> On Sun, Feb 22, 2009 at 01:36:28PM +0100, Michael Neumann wrote:
>> Okay "zpool remove" doesn't seem to work as expected, but it should
>> work well at least for RAID-1 (which probably no one uses for large
>> storage systems ;-). Maybe "zfs replace" works, if you replace an old
>> disk, with a larger disk, and split it into two partitions, the one
>> equally sized to the old, and the other containing the remainder of the
>> space. Then do:
>>
>> zfs replace tank old_device new_device_equally_sized
>> zfs add tank new_device_remainder
>>
>> But you probably know more about ZFS than me ;-)
>
> In this case, yes (that I know more about ZFS than you :-) ). What
> you're trying to do there won't work.
>
> The "zfs" command manages filesystems (e.g. pieces under a zpool). You
> cannot do anything with devices (disks) with "zfs". I think you mean
> "zpool", especially since the only "replace" command is "zpool replace".
>
> What you're trying to describe won't work, for the same reason I
> described above (with your "zpool add tank ad8s1" command). You can
> split the disk into two pieces if you want, but it's not going to
> change the fact that you cannot *grow* a zpool. You literally have to
> destroy it and recreate it for the pool to increase in size.
>
> I've been through this procedure twice in the past year, as I replaced
> 250GB disks with 500GB, and then 500GB disks with 750GB. It's a *huge*
> pain, and I cannot imagine anyone in an enterprise environment using ZFS
> to emulate a filer -- it simply won't work. For individual servers
> (where disks are going to remain the same size unless the box is
> formatted, etc.), oh yes, ZFS is absolutely fantastic.
This is patently false, and you've been creating unnecessary work for
yourself. :)
You most definitely can add drives to a pool, thus increasing the
total amount of storage space available in the pool. It's as simple
as:
zpool add <...>
That's the whole point of the "add" keyword ... you add storage to the
pool. For example, you can create a pool using a 6-disk raidz2 vdev
like so:
zpool create pool raidz2 da0 da1 da2 da3 da4 da5
Later, you can add another raidz2 vdev like so:
zpool add pool raidz2 da6 da7 da8 da9
Your pool has now become, effectively, a RAID60: a RAID0 stripe made
up of two RAID6 arrays.
You can later add a mirrorred vdev to the pool using:
zpool add pool mirror da10 da11
And data will be striped across the three different vdevs. This is
the whole point of the pooled storage setup ... you just keep adding
storage to the pool, and it gets striped across it all.
You're getting tripped up by the same thing that I did when I first
started with ZFS: you can't extend raidz vdevs (ie you can't start
with a 6-drive raidz2 and then later expand it into a 10-drive
raidz2). But there's nothing stopping you from adding more raidz2
vdevs to the pool.
One of the servers we have at work uses 3x 8-drive raidz2 vdevs:
[fc...@thehive ~]$ zpool status
pool: storage
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
storage ONLINE 0 0 0
raidz2 ONLINE 0 0 0
label/disk01 ONLINE 0 0 0
label/disk02 ONLINE 0 0 0
label/disk03 ONLINE 0 0 0
label/disk04 ONLINE 0 0 0
label/disk13 ONLINE 0 0 0
label/disk14 ONLINE 0 0 0
label/disk15 ONLINE 0 0 0
label/disk16 ONLINE 0 0 0
raidz2 ONLINE 0 0 0
label/disk05 ONLINE 0 0 0
label/disk06 ONLINE 0 0 0
label/disk07 ONLINE 0 0 0
label/disk08 ONLINE 0 0 0
label/disk17 ONLINE 0 0 0
label/disk18 ONLINE 0 0 0
label/disk19 ONLINE 0 0 0
label/disk20 ONLINE 0 0 0
raidz2 ONLINE 0 0 0
label/disk09 ONLINE 0 0 0
label/disk10 ONLINE 0 0 0
label/disk11 ONLINE 0 0 0
label/disk12 ONLINE 0 0 0
label/disk21 ONLINE 0 0 0
label/disk22 ONLINE 0 0 0
label/disk23 ONLINE 0 0 0
label/disk24 ONLINE 0 0 0
errors: No known data errors
[fc...@thehive ~]$ zpool list
NAMESIZEUSED AVAILCAP HEALTH ALTROOT
storage10.9T 3.90T 6.98T35% ONLINE -
--
Freddie Cash
fjwc...@gmail.com
Re: OT - was Hammer or ZFS based backup, encryption
On Sun, Feb 22, 2009 at 6:33 AM, Jeremy Chadwick wrote: > I've been through this procedure twice in the past year, as I replaced > 250GB disks with 500GB, and then 500GB disks with 750GB. It's a *huge* > pain, and I cannot imagine anyone in an enterprise environment using ZFS > to emulate a filer -- it simply won't work. For individual servers > (where disks are going to remain the same size unless the box is > formatted, etc.), oh yes, ZFS is absolutely fantastic. Oh, and you don't have to re-create the pool in order to use the extra space. Just "zpool replace" the drives with larger ones, then "zpool export" the pool, and "zpool import" the pool, and the extra space becomes available. I did this on my home server a couple of months ago. I started with 3x 120 GB drives split into 3 slices (2 GB for use by gmirror for /, 1 GB for use as swap, rest for use by ZFS). Later I moved / onto a 2 GB USB key. A simple iteration of "zpool replace pool ad4s1 ad4" for each of the three drives, an export and import, and I had an extra 9 GB of space in my pool. -- Freddie Cash fjwc...@gmail.com
Re: Hammer on snapshot cd's
On Wed, Jul 16, 2008 at 1:41 AM, Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote: > Matthew Dillon wrote: >> >> :> cc -Wall x.c -c -O2 >> :> x.c: In function 'fubar2': >> :> x.c:16: warning: 'error' is used uninitialized in this function >> :> :> (edit so *valuep is set to 0) >> :> :> cc -Wall x.c -c -O2 >> :> (no warning reported) >> : >> :So you need to go -O2? -O alone doesn't work? Maybe we should -O2 >> :after the release then :) >> : >> :cheers >> : simon >> >>No, we will always stick to -O. GCC is a moving target too, even if >>-O2 works now there is a high chance it will break something in future >>GCC rolls. > > Why should -O2 break things and -O never break things? That doesn't seem > obvious to me. I think all the breakages that happened in the last couple > of years which were connected with optimization happened with -O, -O2 and > -Os. > > There seems to be a traditional, irrational fear of -O2 in the FreeBSD > community, which I can't explain. I've heard something about -O2 and inline > assembly, but that's probably old as well. The default CFLAGS for FreeBSD 7+ (possibly 6+) includes -O2. -- Freddie Cash [EMAIL PROTECTED]
Re: fdisk implementation
On Thu, Jul 10, 2008 at 3:43 AM, Jost Tobias Springenberg <[EMAIL PROTECTED]> wrote: > On Wed, 9 Jul 2008 10:27:49 -0700 > "Freddie Cash" <[EMAIL PROTECTED]> wrote: >> On Tue, Jul 8, 2008 at 10:35 AM, Matthew Dillon >> >We could probably use a new fdisk, I think this would be a good >> >project. >> >> You may want to have a look at >> http://www.freshports.org/sysutils/sfdisk/ This is the fdisk tool >> used in sysinstall, and has a decent interface. It's similar to >> cfdisk from the Linux-world (but nicer to use IMO). > > Ok I guess I will take a look at it tonight and also search for alternatives. > I'll have 2 weeks of time during the next 2 months so it should be possible > to finish this. > Question to the sfdisk, I am not an expert regarding FreeBSD code, > but doesn't sfdisk depend on some internal FreeBSD disk abstractions ?? Sorry, couldn't tell you about that. I'm just a user of sfdisk, don't know anything about its internals. -- Freddie Cash [EMAIL PROTECTED]
Re: fdisk implementation
On Tue, Jul 8, 2008 at 10:35 AM, Matthew Dillon <[EMAIL PROTECTED]> wrote: > :just a quick sidenote... while I decided to finally play around with hammer > :I had to fiddle around with dragonfly's fdisk implementation and I think it > is a mess! > :The menu driven mode is horrible, and absolutely not self explaining. > :We should definitely adapt the OpenBSD or newer FreeBSD version. > :Is there any reason there could occur bigger problems with this ? > :Otherwise I'm actually willing to try to port it over during my semester > break, > :because I really believe it is necessary to do this. > :If there is any special super mode I missed about the fdisk we are using > right now just let me know! > :Regards, > :Tobias > : > :-- > :Jost Tobias Springenberg <[EMAIL PROTECTED]> > >We could probably use a new fdisk, I think this would be a good >project. You may want to have a look at http://www.freshports.org/sysutils/sfdisk/ This is the fdisk tool used in sysinstall, and has a decent interface. It's similar to cfdisk from the Linux-world (but nicer to use IMO). -- Freddie Cash [EMAIL PROTECTED]
Re: 7-Zip / Bzip2
On Sun, May 11, 2008 at 11:22 AM, Joerg Sonnenberger <[EMAIL PROTECTED]> wrote: > On Sun, May 11, 2008 at 10:46:38AM -0700, Freddie Cash wrote: >> Instead of pulling in another app, consider pulling in libarchive and >> friends from FreeBSD 6+, and then adding 7z support to that. > > You know that one of the two reasons I wrote the compression_program > support in libarchive was 7z's lack of a proper library interface? Well, there you go. :) It looks like all the pieces are in place. What more needs to be done? ;) -- Freddie Cash [EMAIL PROTECTED]
Re: 7-Zip / Bzip2
Compression algorithms are something that should be handled via an extendle library. And the front-end apps (gzip, bzip2, 7z, etc) should just use that library to do the heavy lifting. Instead of pulling in another app, consider pulling in libarchive and friends from FreeBSD 6+, and then adding 7z support to that. Then you can remove compress, gzip, gunzip, bzip2, bunzip2, 7z, etc, and just put in stub programs that call the library functions. -- Freddie Cash [EMAIL PROTECTED]
Re: Xen vs VMware
On Sun, October 22, 2006 9:41 am, Andreas Hauser wrote: > wa1ter wrote @ Sat, 21 Oct 2006 10:25:31 -0700: >> Andreas Hauser wrote: >>> dillon wrote @ Wed, 18 Oct 2006 11:34:02 -0700 (PDT): >>> Unless you use a current processor (Intel or Amd e.g.) which come >>> with hardware virtualization... >> >> Can you point out which processors have this hardware -- are they >> the 64-bit models only? My instincts tell me that the 64-bit >> hardware could virtualize a 32-bit machine -- but that's a pure >> guess on my part. > > No, it has nothing to do with 32-bit or 64-bit. > Amd calls it Pacifica and Intel Vanderpool or VT. > Newer Athlon 64 (AM2), Opteron, Core 2, All Intel from Apple etc. > have it. AFAIR the non Apple mobile Core don't have it. The codenames for the hardware virtualisation projects are Pacifica for AMD and Vanderpool for Intel. The official release names are AMD-V and Intel-VT. From research I've been doing online, it seems that (again) the AMD implementation is much better, virtualising a lot more of the CPU and providing better support for virtual I/O. The Xen wiki has a nice list of CPU model numbers that have AMD-V and Intel-VT support: http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors Freddie Cash, LPIC-2 CCNT CCLPHelpdesk / Network Support Tech. School District 73(250) 377-HELP [377-4357] [EMAIL PROTECTED]
Re: Xen vs VMware
On Wednesday 18 October 2006 12:42 pm, Steve Mynott wrote: > On 10/18/06, Matthew Dillon <[EMAIL PROTECTED]> wrote: > > Generally speaking I prefer the VMWare concept over the Xen > > concept. Xen actually has to run two operating systems, one serving > > as the master and the other as the 'guest' OS, and this compounds the > > number of potential bugs you might run into a lot more then a machine > > emulator does. > > I'm surprised by this. Xen (abstracting out some sort of meta > operating system) seems a "cleaner" and simplier solution to me than > running a complex software copy of real hardware. > > Anyway aren't we just talking about lines of C in both cases? I > suspect the number of bugs in either would just be a function of the > total lines of C. > > Xen is relatively small. Although vmware source, isn't available > AFAIK would anyone care to estimate lines of source for it? Xen itself is small. However, every OS that you want to run on top of Xen needs to be made Xen-aware, with a custom kernel that uses Xen features. For that reason, you can really only run open-source OSes on top of Xen right now. You also lose the ability to query the hardware (lspci/pciconf for instance return empty statements on Xen) from within the guest OS. VMWare emulates a full PC, with a BIOS and everything. You can run any OS on top of VMWare, without changing the OS in any way. Everything runs the same as if it were installed on real hardware. You can even query the virtual hardware using things like pciconf/lspci. With the new CPUs from Intel/AMD that include hardware virtualisation features, it is theoretically possible to run any OS on top of Xen 3.0+, but I have not heard of anyone successfully doing that as yet (not that I've searched all that hard). Xen's para-virtualisation method is said to be a lot faster than VMWare full virtualisation method. With support for hardware virtualisation features in newer CPUs, VMWare's latest products are supposedly almost as fast as Xen. And they've started using a few para-virtualisation tricks as well to speed things up. Basically, it boils down to whether you want a virtual OS or a virtual PC. Xen is the former, VMWare is the latter. -- Freddie Cash, LPIC-2 CCNT CCLP Helpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED][EMAIL PROTECTED] -- Freddie Cash, LPIC-2 CCNT CCLP Network Support Technician School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED]
Re: Network Slowdowns?
On Sat, October 7, 2006 3:19 am, Bill Hacker wrote: > Jamie wrote: > *SNIP* (all details already posted) > >> (I use 3Com on all machines) > Without digressing into decades of *why*, I can just about guarantee > that replacing the offending card with almost-anything-else, from > el-cheapo Realtek to Gig-E Intel, probable exception of anything-SiS, > will cure the problem without further ado. [snip] > We *always* replace 3Com on general principal when encountered, and > at our own (not client) expense. Not about right or wrong, its about > what works *always* and what doesn't always work. > > The time saved the past dozen years has been more than worth the very > modest cost of replacement NIC's. Life is too short etc. Odd, we do the exact opposite, replacing all non-3Com NICs we come across with 3Com NICs, for the exact same reason you do: to get something that we know works, and works reliably. :) For Windows, Linux, and FreeBSD, the only NICs that we found to work well are 3Com 3C905B and 3C905C series NICs. D-Link, NetGEAR, RealTek, even a lot of Intel chipsets have given us grief in the past. Since standardising on 3Com, we haven't had any problems. Now we just need to find a good, solid, GigE chipset. Freddie Cash, LPCI-2 CCNT CCLPHelpdesk / Network Support Tech. School District 73(250) 377-HELP [377-4357] [EMAIL PROTECTED]
Re: shutdown on BSD and Linux
On Thu, September 7, 2006 3:28 am, Rahul Siddharthan wrote: > I've long had a question on the shutdown process. Linux systems run > a separate shutdown script for every process that was started at boot, > and can take a minute or two to shutdown. FreeBSD and Dragonfly, as > far as I can tell, just kill all processes, flush buffers, unmount > filesystems and shutdown/poweroff, which takes about 5 seconds. Read the rc(8) man page. There's a lot more going on then just "send SIGTERM then SIGKILL to all processes" on BSD systems. The big difference is that Linux init systems show all the shutdown messages for all the scripts, while BSD systems just show generic "Stopping all processes" messages. Freddie Cash, LPIC-2 CCNT CCLPHelpdesk / Network Support Tech. School District 73(250) 377-HELP [377-4357] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: disk diagnostics
On Tue, July 25, 2006 12:34 pm, Bill Hacker wrote: > Pieter Dumon wrote: >> how can I diagnose my disk read/write throughput under DFLy ? my >> system runs well except that untarring even small tar files or >> deleting files takes a lot of time (e.g. the removal of >> /usr/obj/usr/src/world_i386 during a make buildworld takes about 25 >> minutes (I admit it's got a lot of files, but still)). >> >> I don't know if it can have anything to do with my strange >> configuration of having the two harddisks on ATA1 while the CDs are >> on ATA0. The disk with the DFly slice is only UDMA33 (there are no >> DFLy >> slices on the other disk), but still, under windows and linux I >> don't have this slow disk access. >> >> ad2: 28629MB [58168/16/63] at ata1-master UDMA33 >> ad3: 76319MB [155061/16/63] at ata1-slave >> UDMA100 >> acd0: DVD-R at ata0-master PIO4 >> acd1: CDROM at ata0-slave PIO4 > Agree that is not an optimal set up - faster IDE drives uusally fare > best on 80-pin cable to ad0 (master) and ad2 (master) with CD's as > slaves, or better yet, on a PCI-bus add-on controller so there is no > master/slave speed difference. It really depends on what your data transfers across the IDE bus will look like. You want to put the sender and receiver on separate channels (not as master/slave on the same channel), regardless of what the devices are. So, if you do mostly CD->HD or HD->CD transfers (ripping or burning CDs/DVDs) then you will want the HD and CD to be master on separate channels. If you do mostly HD->HD transfers, you will want those as master on separate IDE channels. If you do mostly CD->CD transfers (on-the-fly copying of CDs/DVDs), then you will want them on separate channels (preferably as master, but that's not always possible with only onboard IDE controllers available). If you do a fairly balanced mix of HD->HD and HD->CD, then it doesn't really matter where the devices are. And you'll want your fastest device to be master on the IDE channel, if you have multiple devices per channel. Granted, the best setup is to only have a single device on each IDE channel. And to have add-on IDE controller sitting on separate PCI buses from other devices (if possible). Freddie Cash, LPCI-1 CCNT CCLPHelpdesk / Network Support Tech. School District 73(250) 377-HELP [377-4357] [EMAIL PROTECTED]
Re: Replacing Sendmail with Postfix in the base system
On Wed, June 14, 2006 7:54 am, Justin C. Sherrill wrote: > On Wed, June 14, 2006 9:49 am, [EMAIL PROTECTED] wrote: > Right now, we can switch out to any MTA people want, including > Postfix. Several people have mentioned that you can remove sendmail from the base by just setting NO_SENDMAIL in make.conf and rebuilding the world. BUT, nobody has mentioned if that actually removes the old pieces of sendmail that are already in the filesystem. For example, if you install DFly on a clean harddrive, set NO_SENDMAIL in make.conf, rebuild the world, install the world, reboot, and look in /usr/lib ... will sendmail still be there? If it is, then someone should probably have a look at revamping the build process so that those bits listed as NO_* in make.conf are actually removed. Just because you can build the world with sendmail support (or bind support, or whatever support) doesn't mean those pieces are actually removed from the running system. >From my experience, the only way to actually remove bits of DFly (or FreeBSD) is to add all the NO_* entries to make.conf, then build a new release, and reinstall the system using those release bits, aftering formating the drive. So, saying you can "just remove sendmail" is a little misleading. :) (Unless things have changed in DFly, of course. In which case, point me to the docs, and I'll keep quiet.) IMO (which counts for as much as a lady-bug's), sendmail should be removed from base completely. Include a simple local-only mailer. Then add an option to the installer that asks which MTA the user would like, and install that using packages built from pkgsrc (similar to how Perl was removed from FreeBSD's base in 5.x, but still gets installed as a package). Have the package install edit mailer.conf to point to the correct binaries. Voila! Everyone can have their MTA and eat it too! Freddie Cash, LPCI-1 CCNT CCLPHelpdesk / Network Support Tech. School District 73(250) 377-HELP [377-4357] [EMAIL PROTECTED]
Re: A mobile user's wishlist
On Tuesday 06 June 2006 12:02 pm, Thomas Schlesinger wrote: > Am Dienstag, 6. Juni 2006 20:43 schrieb Freddie Cash: > > KControl -> Power Control -> Laptop Battery doesn't work for you? > > This starts the klaptop daemon that monitors the battery. I haven't > > tried it on DFlyBSD, but it worked nicely for me in FreeBSD. It's > > part of the KDE release, although I do not recall exactly which part > > includes it. > the klaptopdaemon works in Linux on my notebook, but sadly not in > DragonFlyBSD. Hmmm, of course. That would have made it simple. :) I had it working on my FreeBSD 5.3 box a long time ago, but haven't played with it since then on a BSD (all my GUI stations are Debian/Kubuntu). -- Freddie Cash, LPIC-1 CCNT CCLP Helpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED]
Re: A mobile user's wishlist
On Tuesday 06 June 2006 12:23 pm, Rob Andrews wrote: > On 06-Jun-2006 19:23.23 (BST), Thomas Schlesinger wrote: > > 2. A module for better synaptics touchpad support > > My touchpad works, but from Linux I'm used to do vertical scrolling > > with the right border of my touchpad, like a mouse scroll-wheel. The > > source code is available here: > > http://web.telia.com/~u89404340/touchpad/ > I don't know about console, but isn't the xorg 'synaptics' module > enough to get that working? Not sure if it's in pkgsrc or not, but there's also a qtsynaptics and ksynaptics GUI for configuring synaptic touchpads. -- Freddie Cash, LPIC-1 CCNT CCLP Helpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED]
Re: A mobile user's wishlist
On Tuesday 06 June 2006 11:23 am, Thomas Schlesinger wrote: > I'm using DragonFlyBSD for a few weeks now on my notebook an miss some > pieces of software: > 3. A battery tool for KDE > gkrellm is available, but as a KDE user I would like to see something, > that fits better in the KDE desktop. The DesktopBSD guys have created a > nice tool for that: > http://www.freebsd.org/cgi/pds.cgi?ports/sysutils/desktopbsd-tools . > There's also a tool in KDE's svn repository: > http://websvn.kde.org/trunk/kdenonbeta/kbatterymonitor/ KControl -> Power Control -> Laptop Battery doesn't work for you? This starts the klaptop daemon that monitors the battery. I haven't tried it on DFlyBSD, but it worked nicely for me in FreeBSD. It's part of the KDE release, although I do not recall exactly which part includes it. There's also the KPowersave daemon, although I believe it might be very Linux-specific. -- Freddie Cash, LPIC-1 CCNT CCLP Helpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED]
Re: Sound question.
On Thu, June 1, 2006 12:31 pm, Max von Seibold wrote: > Sorry for a somewhat open question here. I have just installed > Dragonfly on my machine and am considering which directions to take > with sound. > Can anyone tell me which sound server they would recommend (I saw > JACK in the pkgsrc list) and have heard good things about it. However > im somewhat daunted about getting ALSA to work... ALSA == Advanced Linux Sound Architecture. ie: it's not available on anything but Linux. :) Getting sound working on BSD is much simpler. Just load the kernel module for all the sound drivers, run "cat /dev/sndstat" to see if the kernel detected your sound chipset, then add a line to /boot/loader.conf to autoload that kernel module at boot. I do not remember what the kernel module name is to load all the sound drivers on FreeBSD4/DFlyBSD, though. I think it's just snd (kldload snd; cat /dev/sndstat). Anyway, read through the snd(4) man page, and all the man pages referenced by it. Getting sound working on BSD is easy, if the chipset is supported. :) Freddie Cash, LPCI-1 CCNT CCLPHelpdesk / Network Support Tech. School District 73(250) 377-HELP [377-4357] [EMAIL PROTECTED]
Re: Any serious production servers yet?
On Wed, May 31, 2006 11:50 am, Danial Thom wrote: > --- Matthew Dillon <[EMAIL PROTECTED]> wrote: >> Er. Well, if I were talking about today I would be talking about >> today. I'm talking about the near-future, 2-3 years from now. It >> would be the height of stupidity to have programming goals that >> only satisfy the needs of today. > It might be the "height of stupidity", but it takes 2-3 years to > convince people that you have something worth using, even if you have > something great, so are you prepared to wait 4-5 to have a mainstream > O/S? Once you get the groundwork done, you should ramp up to be > production quality so you can get some noteworthy people using the > O/S in real-world servers. Then you can keep it stable and work in > your roadmap. > We're approaching a critical point where a lot of companies are going > to start looking to move into MP who haven't been there before. > Saying you'll have something really great in 2 years isn't going to > get people involved with the project. > Your project will move ahead at an exponential pace once you get more > funding and more important people working on it. You can't do that > with an OS that can't be used by anyone with the money to contribute. > You're thinking like an engineer, and not a marketeer. Its sort of ^^^ Thank god for that. It's about time!! There are two many OSes out there that are managed by the marketing dept. Marketers should not get involved with an OS at the get go, or even in the first few years. We need more engineers working on OSes, not more marketing droids and script kiddies testing out their compiler for the first time. :D
Re: make -jn not necessarily helpful
On Tue, March 14, 2006 4:42 pm, Justin C. Sherrill wrote: > On Tue, March 14, 2006 12:03 pm, Freddie Cash wrote: >> Try moving the make clean to the end, and rebooting between runs. >> That will eliminate any caching or disk buffering that may be >> happening. > That step I pasted repeated with different -j levels, so a 'make > clean' happened after and before every step. > I can't imagine something as large as a 'make buildworld' would be > significantly cached, and even if it was, then I'd see a sudden > performance improvement after the first run. >> I haven't timed the buildworld runs on my systems in a long time, >> but the last time I did, -j2 was faster than -j1 on a UP system. >> All higher -j settings were slower. And on a dual-Opteron sytem, >> -j4 and -j6 alternated between being the fastest. > If you have a system on which you can try it, I'd like to know the > results. I suspect there may be a cutoff where this does not help, > and I want to define this better than the folklore it is now. I don't have any DragonFlyBSD systems anymore, but I ran a buildworld loop on a FreeBSD 6.0p4 system at work. It's a dual-AthlonMP 2200+ with 4 GB RAM and a single 80 GB ATA100 HD. I ran a for loop that did: make cleanworld make clean make cleandir make clean make -jX buildworld with X values of 1 through 20. Attached are my results. -j1 is the slowest by over 40 minutes. -j3 is the fastest by a measly minute and a bit. -j2 through -j20 are all within 3 minutes of eachother. On this system, I'd have to guess that three make processes are able to access the disk at one time, and the rest just spend their time waiting to access the disk. We have a spare rackmount here (dual-Opteron 244, 4 GB RAM, 4x 150 GB SATA drives connected to a 3Ware Escalade 9550SX RAID controller). I'll see if I can get FreeBSD installed and run through the same tests. The I/O should be much less of a bottleneck in this system, and it should get a better gain from the higher -jX values. That's my thoughts, anywho, we'll see what it actually does. :) Freddie Cash, LPCI-1 CCNT CCLPHelpdesk / Network Support Tech. School District 73(250) 377-HELP [377-4357] [EMAIL PROTECTED]Wed Mar 15 08:15:18 PST 2006 Testing make -j1 ... Wed Mar 15 10:30:02 PST 2006 done -- 2 hours 15 mins Wed Mar 15 10:31:59 PST 2006 Testing make -j2 ... Wed Mar 15 11:51:14 PST 2006 done -- 1 hours 20 mins Wed Mar 15 11:53:12 PST 2006 Testing make -j3 ... Wed Mar 15 13:11:55 PST 2006 done -- 1 hours 18 mins Wed Mar 15 13:13:52 PST 2006 Testing make -j4 ... Wed Mar 15 14:33:08 PST 2006 done -- 1 hours 20 mins Wed Mar 15 14:35:04 PST 2006 Testing make -j5 ... Wed Mar 15 15:54:07 PST 2006 done -- 1 hours 21 mins Wed Mar 15 15:56:04 PST 2006 Testing make -j6 ... Wed Mar 15 17:14:55 PST 2006 done -- 1 hours 18 mins Wed Mar 15 17:16:50 PST 2006 Testing make -j7 ... Wed Mar 15 18:35:47 PST 2006 done -- 1 hours 19 mins Wed Mar 15 18:37:42 PST 2006 Testing make -j8 ... Wed Mar 15 19:56:48 PST 2006 done -- 1 hours 19 mins Wed Mar 15 19:58:43 PST 2006 Testing make -j9 ... Wed Mar 15 21:17:43 PST 2006 done -- 1 hours 19 mins Wed Mar 15 21:19:38 PST 2006 Testing make -j10 ... Wed Mar 15 22:38:48 PST 2006 done -- 1 hours 19 mins Wed Mar 15 22:40:42 PST 2006 Testing make -j11 ... Thu Mar 16 00:00:02 PST 2006 done -- 1 hours 20 mins Thu Mar 16 00:01:58 PST 2006 Testing make -j12 ... Thu Mar 16 01:21:27 PST 2006 done -- 1 hours 20 mins Thu Mar 16 01:23:22 PST 2006 Testing make -j13 ... Thu Mar 16 02:42:44 PST 2006 done -- 1 hours 19 mins Thu Mar 16 02:44:39 PST 2006 Testing make -j14 ... Thu Mar 16 04:05:17 PST 2006 done -- 1 hours 21 mins Thu Mar 16 04:07:14 PST 2006 Testing make -j15 ... Thu Mar 16 05:26:49 PST 2006 done -- 1 hours 19 mins Thu Mar 16 05:28:45 PST 2006 Testing make -j16 ... Thu Mar 16 06:48:18 PST 2006 done -- 1 hours 10 mins Thu Mar 16 06:50:13 PST 2006 Testing make -j17 ... Thu Mar 16 08:09:53 PST 2006 done -- 1 hours 19 mins Thu Mar 16 08:11:48 PST 2006 Testing make -j18 ... Thu Mar 16 09:31:25 PST 2006 done -- 1 hours 10 mins Thu Mar 16 09:33:20 PST 2006 Testing make -j19 ... Thu Mar 16 10:53:11 PST 2006 done -- 1 hours 20 mins Thu Mar 16 10:55:07 PST 2006 Testing make -j20 ... Thu Mar 16 12:15:05 PST 2006 done -- 1 hours 20 mins
Re: make -jn not necessarily helpful
On Mon, March 13, 2006 8:52 pm, Justin C. Sherrill wrote: > Out of curiousity, I thought I'd try running make buildworld with the > -j option in a few different configurations to see what difference > it made. I know it's supposed to speed up the process by a certain > amount because of the parallel processing, but there's no direct > quantifier. > I put together a shell script that had this several times over > make clean > echo `date` >> /home/justin/benchmark.txt > echo 'make -j2 buildworld' >> /home/justin/benchmark.txt > make -j2 buildworld > echo `date` >> /home/justin/benchmark.txt > echo " " >> /home/justin/benchmark.txt > I did this with no -j, -j1, -j2, and -j3 Try moving the make clean to the end, and rebooting between runs. That will eliminate any caching or disk buffering that may be happening. I haven't timed the buildworld runs on my systems in a long time, but the last time I did, -j2 was faster than -j1 on a UP system. All higher -j settings were slower. And on a dual-Opteron sytem, -j4 and -j6 alternated between being the fastest. Freddie Cash [EMAIL PROTECTED]
Re: recommend kvm switch
> The nice thing about IOGear KVM's is that they come with cables and > are at a decent price. The one I have at home cost me about 150 bucks > but that was about 2-3 years ago. They cost much less these days, > though. > Seems like alot of people here have had good luck with Belkin. > Personally, I will never buy a belkin product again. I have had an 8 > port KVM and a 4 port KVM crap out on me. I've had problems with other > Belkin products as well. Guess it all depends on the product / use. :) We (the school district) have 20 4-port Belkin OmniView KVMs in various schools, as well as 4 8-port KVMs daisy-chained in the server room. All came with cables (early ones were nice, all three cables in one sheath, later ones were just extension cables twist-tied together). And only 1 died due to overheating under a desk. :) -- Freddie Cash, CCNT CCLPHelpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: recommend kvm switch
On November 30, 2005 01:14 pm, Bob Bagwill wrote: > Can anyone recommend a really bullet-proof 2 or 4 port kvm switch > (that's DBSD compatible)? Thanks. The Belkin 2-port (with built-in cables), 4-port, and 8-port KVM switches work really well. Tested with Windows 98/XP, FreeBSD 4.10/4.11/5.3/5.4/6.0, and an early release of DFly (1.0 or 1.2). The only issue with BSD is that you either have to boot with the KVM set to that port, or add flags=0x100 to the keyboard driver (atkbd I think). Otherwise, the keyboard won't work for that boot session. -- Freddie Cash, LPIC-1 CCNT CCLP Helpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED]
Re: Warning about installing DragonFly and FreeBSD to same disk
On August 25, 2005 12:45 pm, Rob Andrews wrote: > [25-Aug-2005 17:59.00 (BST) / Chris Pressey] > > I haven't tested any workarounds yet, but I suspect that marking > > the DragonFly partition with some other partition id (like MS-DOS) > > before installing, and marking it back after installing, would be > > enough to trick FreeBSD's installer into ignoring it. > grub has an option "parttype" that can change the partition type > before proceeding with the boot process. I used it to change > freebsd's partition type back to 0 and dragonfly's to 165 before > booting dragonfly, and vice versa for freebsd. Popping this into the > menu file will do the grunt for you at boot time. > If you install the loader to the FreeBSD and DragonFly partition boot > sectors and skip the MBR loader installation you can install grub and > have it chain load the boot loader from the boot sector. > Be warned, grub may not support the ufs filesystem you choose to > install it upon. If grub can't read the stage2 files from your > filesystem, keep an ext2 or FAT filesystem somewhere. GRUB 0.9.5 and above supports UFS1 and UFS2. And you don't need to use chainloader to load the BSD loader. You just set the kernel option in GRUB to /boot/loader. I used GRUB 0.9.5 to tripleboot FreeBSD 4.8-4.11 and 5.2.1-6.0B2, and Windows XP (using chainloader and makeactive for XP) without issues. Haven't tried with DragonFlyBSD, but it should work. -- Freddie Cash, CCNT CCLPHelpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED]
Re: Compatability with FreeBSD Ports [debian package tools]
On August 17, 2005 11:06 am, Michel Talon wrote: > Matthew Dillon wrote: > >Illusion. Every time I have ever used portupgrade, the result > > has been a completely broken system. Every time. > This is nice to know, i was under the impression i was so dumb as > being unable to use portupgrade (yes, my experience is not far from > yours) when so many people swear on the bible that they regularly > upgrade their machine with portupgrade without a single hiccup :-) As with all things in life, it depends on how you use it. :) If you avoid the -a option, only use -r and -R when you know exactly which parts will be upgraded and what order they will be upgraded in, and only do a couple apps at a time, then it works wonderfully. I used it regularly on my home servers, my work laptop, 15 firewalls, 12 proxy servers, 2 e-mail servers, and a couple of workstations (running FreeBSD 4.x, 5.x, and 6-CURRENT) from the time it hit the ports tree to now without ever hosing a system or an app upgrade (with the exception of the first time I tried to upgrade perl or KDE without reading UPDATING). And that includes perl, X, and KDE upgrades. I've since moved package building to a central build server and only use the -PP option to portupgrade on the remote systems, and it still works fine. I see a lot of posts on various forums and mailing lists where people have hosed their systems, and every single one of them starts out "I ran portupgrade -arR and now my system is hooped". And everytime I get people to re-do the upgrade without using -arR, things work for them. :) IMO, it would be nice if the -a, -r, and -R options were removed from portupgrade. :) But, then, nobody would have anything to complain about or to fix, since their systems would still be running correctly. :D -- Freddie Cash, CCNT CCLPHelpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED]
