Re: Large (3TB) HDD support
On Fri, Jun 01, 2012 at 09:06:28PM -0400, Scott McEachern wrote: > On 06/01/12 20:54, Christian Weisgerber wrote: > >David Diggles wrote: > > > >>I fsck'd two 3TB filesystems yesterday with 512MB ram, on 5.1... > >>it took a while, but worked. > >I just fsck'ed a 2.7TB filesystem in 1 minute, 43 seconds. > >61% full, 447166 files. > > > > What CPU and how much RAM? SATA2 or 3? Even more important: block size, fragment size, # of inodes? -Otto > > -- > Scott McEachern > > https://www.blackstaff.ca
细谈2
你好! 我公司現有:國際貨運，商品銷售，貨物銷售，商業統一，工業統一， 建築安裝，服務業，廣告業，增值稅等 各種提供;有需要請跟 聯系:張小姐 電話: 13632811220 Q Q: 592685507
Re: Large (3TB) HDD support
On 06/01/12 19:18, Eric Furman wrote: Looks like Nick and OBSD could use a Donation. Anyone here in the community willing to step up and donate a couple 3TB drives? I would if I could so I understand if some people can't, but I'm sure there are a few people out there. I'm willing to step up. Hopefully, between your post and mine, we can get people to look under their cushions for spare change. :) I buy the CD sets and accessories like the rest of you, but honestly, it's been too long since I donated. Time to fix that situation. I could swing another 3TB drive, which is about $200 CDN, but not a pair. It was going to be my spare for the RAID array, but hey, it's time to give something back. My only question is whether the $200 for a 3TB drive is the best use of my donation. Is a big HDD actually useful to anyone? Would the money be better applied to something else that OpenBSD can use? It strikes me as rather pointless to order another drive, pay for shipping (even though it's only about $8), have it arrive and then ship it to someone else. (I'm sure my credit card company would be curious about why I'm buying something and having the goods shipped to a different address, possibly half-way around the world.) Enough of my yapping. I'm not interested in debating what's the best idea. I'm sure Theo can figure that out. Time to put up, and shut up, so I'm outta here. Order number 2012/6/1-19:42:43-30258: Your order currently is: -> CDN $200.00 [DON] DONATION to the OpenBSD Project -> Total: CDN $200.00 + Shipping. Danke, -- Scott McEachern https://www.blackstaff.ca
Re: Large (3TB) HDD support
On 06/01/12 20:54, Christian Weisgerber wrote: David Diggles wrote: I fsck'd two 3TB filesystems yesterday with 512MB ram, on 5.1... it took a while, but worked. I just fsck'ed a 2.7TB filesystem in 1 minute, 43 seconds. 61% full, 447166 files. What CPU and how much RAM? SATA2 or 3? -- Scott McEachern https://www.blackstaff.ca
Re: Large (3TB) HDD support
On 06/01/12 15:13, Otto Moerbeek wrote: Do a 'b *' command here, see the man page. That will make the whole disk available and the a command will do what you expect. -Otto Thank-you Otto and others for your assistance, that did the trick! I got both drives online, and set them up as a RAID 1 volume. A little geek porn if I may (I've never seen anything quite like that before. Ha! Until sthen@ posted his message): # df -h /st4 Filesystem SizeUsed Avail Capacity Mounted on /dev/sd3a 2.7T8.0K 2.6T 0%/st4 Some snipped dmesg: sd3 at scsibus3 targ 1 lun 0: SCSI2 0/direct fixed sd3: 2861588MB, 512 bytes/sector, 5860532640 sectors Now I can lighten the load on some of my other drives. :) On 06/01/12 15:27, Nick Holland wrote: 0/direct fixed naa.50014ee001cbd923 sd0: 476940MB, 512 bytes/sector, 976773168 sectors sd1 at scsibus0 targ 1 lun 0: SCSI3 0/direct fixed naa.5000c5004a6e56f1 sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors sd2 at scsibus0 targ 2 lun 0: SCSI3 0/direct fixed naa.5000c5004a5baa2e sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors Life is good. Oh, indeed! However, it'll take me at least a week to xfer my DVD stuff onto it... A few words of warning... * This really messes up your ability to multiboot, as non-OpenBSD OSs will think anything beyond the fdisk/MBR partition might be available. But then, most other OSs choke pretty badly at this point anyway. may not be that big a problem. I won't be multibooting this box any more. (It was once a triple boot WinXP/Win7/OpenBSD machine.) These days, I just buy really cheap used PCs for my occasional Windows needs. Life is easier with cheap hardware than bothering with multiple OSes on one box. * Lots of BIOSes that see >128G disks still won't let you boot from partitions higher than 128G. * I haven't actually TRIED this. I was planning on buying a 3TB disk to experiment on and update FAQ14...but just before I did, there was this little flood issue, and being a cheapskate, I didn't want to sink a lot of money into a drive I didn't really need quite yet (or more accurately, I need TWO of...) I was in the exact same boat; I'm a cheapskate too. I watched the same model drive double in price (about $180 CDN to about $400) overnight, and eventually they went down to $170. I kept scratching my chin on the idea, and the last straw was when (yet again) if I wanted a file (typically a movie), I'd have to dig up the DVD. I literally have hundreds of DVDs. It's seriously inconvenient to buy blanks, burn the data, hope it hasn't degraded when you need it, load it back... I figured "Screw it", take the plunge. I think you know what I'd recommend... :) * Rebuilding the mirror will be a beast. * you don't want to fsck a 3TB file system, 'specially if it is rebuilding the mirror at the same time, though with 12G RAM, you might be able to do it. Nick. I'm hoping luck will stay on my side and I don't have to rebuild any time soon. And if things go sideways, which I always assume, I have other workstations I can use (that one just happens to be the 'best'). Good eye on noticing the 12GB of RAM; I'm sure that will come in handy when things go wrong. I'll be ordering a third 3TB drive as a spare, but in a while. I don't want them all to be from the same batch. I have a web server (Pentium 4) with two 40GB drives in RAID 1 as well, plus a spare in storage. (Not a typo, 40GB.) As you've written before, don't trust it, test it, so I pulled a drive, threw in my spare and let it rebuild. I believe that took half a day. I'm sure 3TB will be very, very ugly even on a machine considerably faster than a P4. BTW, I'm nicely UPSed and have pretty reliable hydro where I live, but stuff happens. That Pentium 4 with the 1.5TB drive only has 1GB of RAM, but I've been pleasantly surprised on the couple of times it's had to fsck the drive. I believe it only took about 10 minutes for it to sort things out the last time, but it's pretty much read-only. So thanks again folks for the advice! -- Scott McEachern https://www.blackstaff.ca
Re: Large (3TB) HDD support
David Diggles wrote: > I fsck'd two 3TB filesystems yesterday with 512MB ram, on 5.1... > it took a while, but worked. I just fsck'ed a 2.7TB filesystem in 1 minute, 43 seconds. 61% full, 447166 files. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Large (3TB) HDD support
On 2012-06-01, Chris Cappuccio wrote: > Nick Holland [n...@holland-consulting.net] wrote: >> * you don't want to fsck a 3TB file system, 'specially if it is >> rebuilding the mirror at the same time, though with 12G RAM, you >> might be able to do it. >> > > Isn't this situation seriously improved with fsck in 5.1 ? Quite a lot. But you might still want to bump -i when you newfs (unless you actually need all those inodes). Default is based on the frag size, but there's a limit to frag size, so it stops scaling back the inode count after a point, and lots of inodes can really slow down fsck. If the majority of your files are "media" you might want to increase it a bit, if you're keeping large backups you might want to increase it a lot. From a bacula box... $ df -hi /bak Filesystem SizeUsed Avail Capacity iused ifree %iused Mounted on /dev/sd2m 2.7T1.4T1.2T56% 146 175212 0% /bak
Re: Large (3TB) HDD support
On Fri, 01 Jun 2012 13:41:21 -0600 Theo de Raadt wrote: > UEFI arrived with all sorts of promises of making machines better, but > is being turned into something completely nefarious. http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement Imagine if it came out before Vista and stopped everyone going back to the shops for XP ;-)
Re: Large (3TB) HDD support
On Fri, Jun 01, 2012 at 04:32:19PM -0700, Chris Cappuccio wrote: > Nick Holland [n...@holland-consulting.net] wrote: > > * you don't want to fsck a 3TB file system, 'specially if it is > > rebuilding the mirror at the same time, though with 12G RAM, you > > might be able to do it. > > > > Isn't this situation seriously improved with fsck in 5.1 ? > I fsck'd two 3TB filesystems yesterday with 512MB ram, on 5.1... it took a while, but worked.
Re: [OBSD Misc] Re: Large (3TB) HDD support
> On Fri, Jun 1, 2012, at 03:27 PM, Nick Holland wrote: > > Otto gave you a good answer here, but I had already provided lots of > > detail, so I'm sending anyway. :) > > > > On 06/01/2012 01:04 PM, Scott McEachern wrote: > > > Hello everyone, > > > > > > I'm hoping that I'm missing something simple (like usual) and maybe > > > someone could straighten me out. > > > > > > I'm trying to add a pair of 3TB drives to my workstation, which I plan > > > on turning into a ~3TB RAID 1 array, and seem to be having difficulty > > > realizing the full size of the drives. > > > > > > The hardware is about a year old, and less than two years old according > > > to the BIOS date: > > > > > > bios0: vendor American Megatrends Inc. version "2103" date 06/18/2010 > > > bios0: ASUSTeK Computer INC. M4A785TD-V EVO > > > > > > (Correction, I've since updated the BIOS to the latest version, just in > > > case, and it reads like so: > > > > > > bios0: vendor American Megatrends Inc. version "2105" date 07/23/2010 > > > > > > and it makes no difference.) > > > > > > (The full dmesg is below, but for now I'll just post the relevant bits.) > > > > > > The BIOS happily reports the two drives as present and of 3.0TB > > > capacity. OpenBSD seems to recognize this as well: > > > > > > sd0 at scsibus0 targ 0 lun 0: SCSI3 > > > 0/direct fixed naa.50014ee001cbd923 > > > sd0: 476940MB, 512 bytes/sector, 976773168 sectors > > > sd1 at scsibus0 targ 1 lun 0: SCSI3 > > > 0/direct fixed naa.5000c5004a6e56f1 > > > sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors > > > sd2 at scsibus0 targ 2 lun 0: SCSI3 > > > 0/direct fixed naa.5000c5004a5baa2e > > > sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors > > > > Life is good. > > > > ... > > > > > I just wanted to get on with my day and not have any fuss, so I issued > > > an "fdisk -iy sd1" command on the way to disklabel'ing things. I suspect > > > that's my error, because fdisk says this: (I've added some commas to > > > make for easier reading.) > > > > > > # fdisk sd1 > > > Disk: sd1 geometry: 364801/255/63 [1,565,565,872 Sectors] > > > Offset: 0 Signature: 0xAA55 > > > Starting Ending LBA Info: > > > #: id C H S - C H S [ start: size ] > > > --- > > > > > > 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > > > 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > > > 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > > > *3: A6 0 1 2 - 97451 165 59 [ 64: 1,565,560,705 ] OpenBSD > > > > > > Uhm, that doesn't seem right > > > > well. it's annoying, but "rightish". :) > > fdisk edits MBRs, MBR has a limit of 2TB on its structures. > > So...it looks like fdisk basically did a 3TB modulo 2TB. I really > > should save myself looking like a fool and check my math, but if I'm > > wrong, it will teach you not to take what I say as gospel :) > > > > Some OSs want you to switch to a new way of handling big disks, but I do > > think OpenBSD will do what you want "natively". > > > > .. > > > A drive with half the capacity seems to have double the numbers, but not > > > for geometry. I suspect that fdisk is lying to me, but I could be wrong. > > > > you are right. > > > > > Let's see what disklabel(8) has to say. On the 1.5TB drive, it looks > > > mostly like this (I've snipped some irrelevant partition data and added > > > commas to make big numbers easier to read): > > .. > > > total sectors: 2,930,277,168 > > > boundstart: 64 > > > boundend: 2930272065 > > > drivedata: 0 > > > > > > 16 partitions: (snipped) > > > # size offset fstype [fsize bsize cpg] > > > c: 2,930,277,168 0 unused > > > > > > On the new 3TB drive, it looks like this: > > > > > > # disklabel sd1 > > .. > > > total sectors: 5,860,533,168 > > > boundstart: 64 > > > boundend: 1565560769 > > > drivedata: 0 > > > > > > 16 partitions: > > > # size offset fstype [fsize bsize cpg] > > > c: 5,860,533,168 0 unused > > > > > > Wait a minute here... disklabel seems to have correct data (ignoring the > > > duid). I'll bet I'm failing at grade four math, but that looks roughly > > > like a 3TB drive. > > > > yes, it's a 3TB disk, but at the moment, disklabel is restricting you to > > just the fdisk-marked part of the drive...which is as it should be. You > > generally don't want your OpenBSD partitions living outside the OpenBSD > > MBR (fdisk) partition. > >EXCEPT when the MBR isn't providing useful info. Like now. > > > > ... > > > At this point I'm wondering WTF is going on. Is this an OpenBSD-specific > > > problem? A BIOS issue? So I unplug all drives except one of the 3TB's, > > > install FreeBSD and tell it to use the whole drive. I get the exact same > > > results from their disklabel. Must be the hardware, right? > > > > What you want to do is use the 'b' option of disklabel to redefine the > > OpenBSD boundaries of the disk. I do believe it will let you specify > > the whole disk, and you can then do what you want. > > > > A few words of warning... > > > > * This
Re: Large (3TB) HDD support
Nick Holland [n...@holland-consulting.net] wrote: > * you don't want to fsck a 3TB file system, 'specially if it is > rebuilding the mirror at the same time, though with 12G RAM, you > might be able to do it. > Isn't this situation seriously improved with fsck in 5.1 ?
Re: Large (3TB) HDD support
On Fri, Jun 1, 2012, at 03:27 PM, Nick Holland wrote: > Otto gave you a good answer here, but I had already provided lots of > detail, so I'm sending anyway. :) > > On 06/01/2012 01:04 PM, Scott McEachern wrote: > > Hello everyone, > > > > I'm hoping that I'm missing something simple (like usual) and maybe > > someone could straighten me out. > > > > I'm trying to add a pair of 3TB drives to my workstation, which I plan > > on turning into a ~3TB RAID 1 array, and seem to be having difficulty > > realizing the full size of the drives. > > > > The hardware is about a year old, and less than two years old according > > to the BIOS date: > > > > bios0: vendor American Megatrends Inc. version "2103" date 06/18/2010 > > bios0: ASUSTeK Computer INC. M4A785TD-V EVO > > > > (Correction, I've since updated the BIOS to the latest version, just in > > case, and it reads like so: > > > > bios0: vendor American Megatrends Inc. version "2105" date 07/23/2010 > > > > and it makes no difference.) > > > > (The full dmesg is below, but for now I'll just post the relevant bits.) > > > > The BIOS happily reports the two drives as present and of 3.0TB > > capacity. OpenBSD seems to recognize this as well: > > > > sd0 at scsibus0 targ 0 lun 0: SCSI3 > > 0/direct fixed naa.50014ee001cbd923 > > sd0: 476940MB, 512 bytes/sector, 976773168 sectors > > sd1 at scsibus0 targ 1 lun 0: SCSI3 > > 0/direct fixed naa.5000c5004a6e56f1 > > sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors > > sd2 at scsibus0 targ 2 lun 0: SCSI3 > > 0/direct fixed naa.5000c5004a5baa2e > > sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors > > Life is good. > > ... > > > I just wanted to get on with my day and not have any fuss, so I issued > > an "fdisk -iy sd1" command on the way to disklabel'ing things. I suspect > > that's my error, because fdisk says this: (I've added some commas to > > make for easier reading.) > > > > # fdisk sd1 > > Disk: sd1 geometry: 364801/255/63 [1,565,565,872 Sectors] > > Offset: 0 Signature: 0xAA55 > > Starting Ending LBA Info: > > #: id C H S - C H S [ start: size ] > > --- > > > > 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > > 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > > 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > > *3: A6 0 1 2 - 97451 165 59 [ 64: 1,565,560,705 ] OpenBSD > > > > Uhm, that doesn't seem right > > well. it's annoying, but "rightish". :) > fdisk edits MBRs, MBR has a limit of 2TB on its structures. > So...it looks like fdisk basically did a 3TB modulo 2TB. I really > should save myself looking like a fool and check my math, but if I'm > wrong, it will teach you not to take what I say as gospel :) > > Some OSs want you to switch to a new way of handling big disks, but I do > think OpenBSD will do what you want "natively". > > .. > > A drive with half the capacity seems to have double the numbers, but not > > for geometry. I suspect that fdisk is lying to me, but I could be wrong. > > you are right. > > > Let's see what disklabel(8) has to say. On the 1.5TB drive, it looks > > mostly like this (I've snipped some irrelevant partition data and added > > commas to make big numbers easier to read): > .. > > total sectors: 2,930,277,168 > > boundstart: 64 > > boundend: 2930272065 > > drivedata: 0 > > > > 16 partitions: (snipped) > > # size offset fstype [fsize bsize cpg] > > c: 2,930,277,168 0 unused > > > > On the new 3TB drive, it looks like this: > > > > # disklabel sd1 > .. > > total sectors: 5,860,533,168 > > boundstart: 64 > > boundend: 1565560769 > > drivedata: 0 > > > > 16 partitions: > > # size offset fstype [fsize bsize cpg] > > c: 5,860,533,168 0 unused > > > > Wait a minute here... disklabel seems to have correct data (ignoring the > > duid). I'll bet I'm failing at grade four math, but that looks roughly > > like a 3TB drive. > > yes, it's a 3TB disk, but at the moment, disklabel is restricting you to > just the fdisk-marked part of the drive...which is as it should be. You > generally don't want your OpenBSD partitions living outside the OpenBSD > MBR (fdisk) partition. >EXCEPT when the MBR isn't providing useful info. Like now. > > ... > > At this point I'm wondering WTF is going on. Is this an OpenBSD-specific > > problem? A BIOS issue? So I unplug all drives except one of the 3TB's, > > install FreeBSD and tell it to use the whole drive. I get the exact same > > results from their disklabel. Must be the hardware, right? > > What you want to do is use the 'b' option of disklabel to redefine the > OpenBSD boundaries of the disk. I do believe it will let you specify > the whole disk, and you can then do what you want. > > A few words of warning... > > * This really messes up your ability to multiboot, as non-OpenBSD OSs > will think anything beyond the fdisk/MBR partition might be available. > But then, most other OSs choke pretty badly at this point anyway. may > not be that big a problem. > * Lots of BIOSe
Re: Large (3TB) HDD support
> The apparent advantage of GPT over FDISK partitions is that it > can describe partitions > 2TB for systems hosting multiple > OSes. That's all I meant. Sorry that it wasn't clear. US-based missile-armed predator drones by themselves appear useful.
Re: Large (3TB) HDD support
On 06/01/2012 04:55 PM, Theo de Raadt wrote: On the other hand, GPT by itself appears useful. What is useful about GPT? *EVERY USER* has the following simple requirements: 1. I have a machine. 2. I want to install an operating system on it (or, have an operating system installed from the factory) What am I missing -- what is useful about GPT? I guess I mean -- what is *MORE* useful about GPT, compared to the other options already available? I guess I should be even more clear: Does GPT provide any functionality that *EVERY USER* needs? No, it does not. I agree completely that any OS can write any kind of disk label (or none) that it needs. As you say, in the very, very large majority of cases no FDISK or GPT or anything else external to the loaded OS is needed. The apparent advantage of GPT over FDISK partitions is that it can describe partitions > 2TB for systems hosting multiple OSes. That's all I meant. Sorry that it wasn't clear. Geoff Steckel
Re: IPSEC newbie looking to replace vpnc with Openbsd built-in IPSEC vpn
not having any practive with cisco ASA but searching the web have seen several post about openbsd-ipsec + cisco asa and from another mails i have seen it seems pretty easy as long as u have the same crypto transforms in the sides > Date: Fri, 1 Jun 2012 15:48:37 -0400 > From: s.casw...@protocol6.com > To: misc@openbsd.org > Subject: IPSEC newbie looking to replace vpnc with Openbsd built-in IPSEC vpn > > Hi all, > > I am currently using vpnc to connect to a client site (which has an CISCO ASA firewall/vpn endpoint) > This setup works, but everytime I use vpnc from my server it breaks other networking, especially the openvpn tunnels I maintain to other sites. > > I'd prefer to use the built-in IPSEC software in OpenBSD to establish the tunnel instead (and terminate it locally on a tun or tap interface) > > All my attempts so far have failed and I must admit I'm an IPSEC newbie, at least with the OpenBSD tools. > > My vpc.conf file is very simple: > > --- > IPSec gateway ww.xx.yy.zz > IPSec ID somevpn > IPSec secret somesecretString > IKE Authmode psk > --- > > Is there an equivalent config for ipsecctl (and/or isakmpd) that is known to work with remote ASA firewalls? > > Any help or suggestions would be greatly appreciated. > > Thanks in advance. > > :-) > > Sarah
Re: Large (3TB) HDD support
> On the other hand, GPT by itself appears useful. What is useful about GPT? *EVERY USER* has the following simple requirements: 1. I have a machine. 2. I want to install an operating system on it (or, have an operating system installed from the factory) What am I missing -- what is useful about GPT? I guess I mean -- what is *MORE* useful about GPT, compared to the other options already available? I guess I should be even more clear: Does GPT provide any functionality that *EVERY USER* needs? No, it does not.
Re: Large (3TB) HDD support
On 06/01/2012 03:41 PM, Theo de Raadt wrote: 2012/6/1 Tyler Morgan: http://www.openbsd.org/faq/faq14.html#LargeDrive That doesn't mention GPT, which is the problem with drives>2TB. https://en.wikipedia.org/wiki/GUID_Partition_Table Can OpenBSD already boot from a 4TB drive on an UEFI system? Try to buy systems that don't rely on UEFI. In the next few years, prepare to buy systems and find out they require UEFI, and then demand a refund. Prepare for it to get even worse than that. If you buy a UEFI-capable system today, you are giving power to the people who will (in the future) make UEFI-only systems which are incapable of running OpenBSD. UEFI arrived with all sorts of promises of making machines better, but is being turned into something completely nefarious. On the surface, UEFI seems to allow the manufacturer and others to insert any amount of black-box malware during boot. That's enough to make me shudder. Obviously, opportunities abound for that code to prevent "unauthorized" O/Ses from running or subvert them once running. Are there other and larger issues? On the other hand, GPT by itself appears useful. Does it also contain boobytraps? Thanks! Geoff Steckel
ipsec routing with cisco over adsl connections
i agree lets try again!
hi folks
> Date: Fri, 1 Jun 2012 10:55:09 -0700
> From: tyl...@tradetech.net
> To: genesi...@hotmail.com
> Subject: Re: ipsec routing dinamic ip over adsl
>
> On 5/31/2012 7:31 PM, carlos albino garcia grijalba wrote:
i have the following problem
remote office connect to my vpn server in order to connect to the internals
over the ipsec tunnel the office has ip
phones
to connect to call manager over the 192.168.0.0/16 the ip phone
192.168.30.2/28 so the ip phone connect correct but thereis another ip
client a watch the people wants to excract info from the watch who is
over the net 172.1.100.1 th PC that whants to connect to runs over the
10.0.0.89 but i can reach the watch and the watch can not ping over the
172 address space the clientit is a cisco router over ADSL line so
DInamic public IP is on172.1.100.1 --X192.168.30.2--OK
vpn openbsd server
ipsec.conf
ike passive esp from any to {192.168.0.0/16, 10.0.0.0/16, 172.1.0.0/16} peer
any \
main auth hmac-sha1 enc aes-128 group modp1024 \
quick auth hmac-sha1 enc aes-128 psk 1234ABC
ike passive from {192.168.0.0/16, 10.0.0.0/16, 172.1.0.0/16} to any \
main auth hmac-sha1 enc aes-128 group modp1024 \
quick auth hmac-sha1 enc aes-128 psk 1234ABC
ifconfig
bge0: flags=8843 mtu 1500
lladdr 00:11:85:f1:cb:6b
priority: 0
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet A.B.C.D netmask 0xff00 broadcast 148.235.89.255
inet6 fe80::211:85ff:fef1:cb6b%bge0 prefixlen 64 scopeid 0x1
re0: flags=8843 mtu 1500
lladdr 00:22:6b:bd:8a:1e
priority: 0
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255
inet6 fe80::222:6bff:febd:8a1e%re0 prefixlen 64 scopeid 0x2
rl0: flags=8843 mtu 1500
lladdr 00:50:bf:05:3f:6b
priority: 0
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 192.168.100.210 netmask 0xff00 broadcast 192.168.100.255
inet6 fe80::250:bfff:fe05:3f6b%rl0 prefixlen 64 scopeid 0x3
enc0: flags=0<>
priority: 0
groups: enc
status: active
ipsecctl -sall
FLOWS:
flow esp in from 192.168.30.0/28 to 192.168.0.0/16 peer 187.131.59.237 srcid
148.235.89.18/32 dstid 187.131.59.237/32 type use
flow
esp out from 192.168.0.0/16 to 192.168.30.0/28 peer 187.131.59.237
srcid 148.235.89.18/32 dstid 187.131.59.237/32 type require
SAD:
esp tunnel from 187.131.59.237 to 148.235.89.18 spi 0xbed90da8 auth hmac-sha1
enc aes
esp tunnel from 148.235.89.18 to 187.131.59.237 spi 0xda01bfaa auth hmac-sha1
enc aes
netstat -nr -f encap
Routing tables
Encap:
Source Port DestinationPort Proto
SA(Address/Proto/Type/Direction)
192.168.30.0/280 192.168/16 0 0
187.131.59.237/esp/use/in
192.168/16 0 192.168.30.0/280 0
187.131.59.237/esp/require/out
IPSEC newbie looking to replace vpnc with Openbsd built-in IPSEC vpn
Hi all, I am currently using vpnc to connect to a client site (which has an CISCO ASA firewall/vpn endpoint) This setup works, but everytime I use vpnc from my server it breaks other networking, especially the openvpn tunnels I maintain to other sites. I'd prefer to use the built-in IPSEC software in OpenBSD to establish the tunnel instead (and terminate it locally on a tun or tap interface) All my attempts so far have failed and I must admit I'm an IPSEC newbie, at least with the OpenBSD tools. My vpc.conf file is very simple: --- IPSec gateway ww.xx.yy.zz IPSec ID somevpn IPSec secret somesecretString IKE Authmode psk --- Is there an equivalent config for ipsecctl (and/or isakmpd) that is known to work with remote ASA firewalls? Any help or suggestions would be greatly appreciated. Thanks in advance. :-) Sarah
Re: Large (3TB) HDD support
Scott McEachern wrote: > I'm trying to add a pair of 3TB drives to my workstation, which I plan > on turning into a ~3TB RAID 1 array, and seem to be having difficulty > realizing the full size of the drives. The partition table in the MBR is limited to 32-bit numbers. 512 bytes/sector * 2^32 sectors = 2 TB In practice, fdisk -i will create an OpenBSD MBR partition of a size modulo 2 TB. If you don't share the disk with other operating systems, this doesn't matter. In disklabel, use the 'b' command to set the upper end of the OpenBSD disk boundary to the entire size of the disk. You can then make full use of the drive when creating partitions. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Large (3TB) HDD support
On 06/01/2012 03:26 PM, Martin Schrvder wrote: 2012/6/1 Tyler Morgan: http://www.openbsd.org/faq/faq14.html#LargeDrive That doesn't mention GPT, which is the problem with drives>2TB. https://en.wikipedia.org/wiki/GUID_Partition_Table Can OpenBSD already boot from a 4TB drive on an UEFI system? Best Martin OpenBSD doesn't support booting from UEFI/GPT stuff at this point, but it is as needed as being able to boot from the tail of a 1TB disk when your bios only supports the first 32G. or 504M. or 128G. or whatever limit your BIOS has. It isn't needed. Hint: a lot of machines purchased today still have problems BOOTING beyond 128G, even though the BIOS reports the entire disk (and this is clearly a BIOS problem, I have several machines which DO boot fine beyond 128G), and you can use 2TB disks on those systems Just Fine. OpenBSD needs to load the boot loader from something the BIOS recognizes (an MBR/fdisk partition). From there, the OS has to be able to figure out where the rest of the disk is (disklabel). Look Ma, no UEFI! Now, if you want to multiboot four different OSs, and put OpenBSD as the last 500GB of a 3TB disk, not so pretty. Nick.
Re: Large (3TB) HDD support
On Fri, Jun 01, 2012 at 09:26:41PM +0200, Martin Schr?der wrote: > 2012/6/1 Tyler Morgan : > > http://www.openbsd.org/faq/faq14.html#LargeDrive > > That doesn't mention GPT, which is the problem with drives >2TB. > https://en.wikipedia.org/wiki/GUID_Partition_Table > > Can OpenBSD already boot from a 4TB drive on an UEFI system? > > Best >Martin OpenBSD handles >2TB disks fine. A problem is that fdisk cannot correctly partiton such large disks, but disklabel is happy to ignore that fact using the b command. -Otto
Re: Large (3TB) HDD support
> 2012/6/1 Tyler Morgan : > > http://www.openbsd.org/faq/faq14.html#LargeDrive > > That doesn't mention GPT, which is the problem with drives >2TB. > https://en.wikipedia.org/wiki/GUID_Partition_Table > > Can OpenBSD already boot from a 4TB drive on an UEFI system? Try to buy systems that don't rely on UEFI. In the next few years, prepare to buy systems and find out they require UEFI, and then demand a refund. Prepare for it to get even worse than that. If you buy a UEFI-capable system today, you are giving power to the people who will (in the future) make UEFI-only systems which are incapable of running OpenBSD. UEFI arrived with all sorts of promises of making machines better, but is being turned into something completely nefarious.
Re: Large (3TB) HDD support
Otto gave you a good answer here, but I had already provided lots of detail, so I'm sending anyway. :) On 06/01/2012 01:04 PM, Scott McEachern wrote: Hello everyone, I'm hoping that I'm missing something simple (like usual) and maybe someone could straighten me out. I'm trying to add a pair of 3TB drives to my workstation, which I plan on turning into a ~3TB RAID 1 array, and seem to be having difficulty realizing the full size of the drives. The hardware is about a year old, and less than two years old according to the BIOS date: bios0: vendor American Megatrends Inc. version "2103" date 06/18/2010 bios0: ASUSTeK Computer INC. M4A785TD-V EVO (Correction, I've since updated the BIOS to the latest version, just in case, and it reads like so: bios0: vendor American Megatrends Inc. version "2105" date 07/23/2010 and it makes no difference.) (The full dmesg is below, but for now I'll just post the relevant bits.) The BIOS happily reports the two drives as present and of 3.0TB capacity. OpenBSD seems to recognize this as well: sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct fixed naa.50014ee001cbd923 sd0: 476940MB, 512 bytes/sector, 976773168 sectors sd1 at scsibus0 targ 1 lun 0: SCSI3 0/direct fixed naa.5000c5004a6e56f1 sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors sd2 at scsibus0 targ 2 lun 0: SCSI3 0/direct fixed naa.5000c5004a5baa2e sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors Life is good. ... I just wanted to get on with my day and not have any fuss, so I issued an "fdisk -iy sd1" command on the way to disklabel'ing things. I suspect that's my error, because fdisk says this: (I've added some commas to make for easier reading.) # fdisk sd1 Disk: sd1 geometry: 364801/255/63 [1,565,565,872 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start: size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 1 2 - 97451 165 59 [ 64: 1,565,560,705 ] OpenBSD Uhm, that doesn't seem right well. it's annoying, but "rightish". :) fdisk edits MBRs, MBR has a limit of 2TB on its structures. So...it looks like fdisk basically did a 3TB modulo 2TB. I really should save myself looking like a fool and check my math, but if I'm wrong, it will teach you not to take what I say as gospel :) Some OSs want you to switch to a new way of handling big disks, but I do think OpenBSD will do what you want "natively". .. A drive with half the capacity seems to have double the numbers, but not for geometry. I suspect that fdisk is lying to me, but I could be wrong. you are right. Let's see what disklabel(8) has to say. On the 1.5TB drive, it looks mostly like this (I've snipped some irrelevant partition data and added commas to make big numbers easier to read): .. total sectors: 2,930,277,168 boundstart: 64 boundend: 2930272065 drivedata: 0 16 partitions: (snipped) # size offset fstype [fsize bsize cpg] c: 2,930,277,168 0 unused On the new 3TB drive, it looks like this: # disklabel sd1 .. total sectors: 5,860,533,168 boundstart: 64 boundend: 1565560769 drivedata: 0 16 partitions: # size offset fstype [fsize bsize cpg] c: 5,860,533,168 0 unused Wait a minute here... disklabel seems to have correct data (ignoring the duid). I'll bet I'm failing at grade four math, but that looks roughly like a 3TB drive. yes, it's a 3TB disk, but at the moment, disklabel is restricting you to just the fdisk-marked part of the drive...which is as it should be. You generally don't want your OpenBSD partitions living outside the OpenBSD MBR (fdisk) partition. EXCEPT when the MBR isn't providing useful info. Like now. ... At this point I'm wondering WTF is going on. Is this an OpenBSD-specific problem? A BIOS issue? So I unplug all drives except one of the 3TB's, install FreeBSD and tell it to use the whole drive. I get the exact same results from their disklabel. Must be the hardware, right? What you want to do is use the 'b' option of disklabel to redefine the OpenBSD boundaries of the disk. I do believe it will let you specify the whole disk, and you can then do what you want. A few words of warning... * This really messes up your ability to multiboot, as non-OpenBSD OSs will think anything beyond the fdisk/MBR partition might be available. But then, most other OSs choke pretty badly at this point anyway. may not be that big a problem. * Lots of BIOSes that see >128G disks still won't let you boot from partitions higher than 128G. * I haven't actually TRIED this. I was planning on buying a 3TB disk to experiment on and update FAQ14...but just before I did, there was this little flood issue, and being a cheapskate, I didn't want to sink a lot of money into a drive I didn't really need quite yet (or more accurately, I need TWO of...) * Rebuilding the mirror will be a beast. * you don't want to
Re: Large (3TB) HDD support
2012/6/1 Tyler Morgan : > http://www.openbsd.org/faq/faq14.html#LargeDrive That doesn't mention GPT, which is the problem with drives >2TB. https://en.wikipedia.org/wiki/GUID_Partition_Table Can OpenBSD already boot from a 4TB drive on an UEFI system? Best Martin
Re: Large (3TB) HDD support
On Fri, Jun 01, 2012 at 01:04:54PM -0400, Scott McEachern wrote: > Hello everyone, > > I'm hoping that I'm missing something simple (like usual) and maybe > someone could straighten me out. > > I'm trying to add a pair of 3TB drives to my workstation, which I > plan on turning into a ~3TB RAID 1 array, and seem to be having > difficulty realizing the full size of the drives. > > The hardware is about a year old, and less than two years old > according to the BIOS date: > > bios0: vendor American Megatrends Inc. version "2103" date 06/18/2010 > bios0: ASUSTeK Computer INC. M4A785TD-V EVO > > (Correction, I've since updated the BIOS to the latest version, just > in case, and it reads like so: > > bios0: vendor American Megatrends Inc. version "2105" date 07/23/2010 > > and it makes no difference.) > > (The full dmesg is below, but for now I'll just post the relevant bits.) > > The BIOS happily reports the two drives as present and of 3.0TB > capacity. OpenBSD seems to recognize this as well: > > sd0 at scsibus0 targ 0 lun 0: SCSI3 > 0/direct fixed naa.50014ee001cbd923 > sd0: 476940MB, 512 bytes/sector, 976773168 sectors > sd1 at scsibus0 targ 1 lun 0: SCSI3 > 0/direct fixed naa.5000c5004a6e56f1 > sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors > sd2 at scsibus0 targ 2 lun 0: SCSI3 > 0/direct fixed naa.5000c5004a5baa2e > sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors > > (Note that sd0 is my boot/OS drive, and works just fine. The two > 3TB drives, sd1 and sd2, will eventually just be used for storage.) > > Those numbers look correct, like the OS is properly recognizing the > capacity. I have a 1.5TB drive in another machine (a six year-old > Pentium 4 no less!) that works fine and looks like this: > > wd0: 16-sector PIO, LBA48, 1430799MB, 2930277168 sectors > > (Although I should mention that that drive has a couple of <1TB > partitions, so there are no FFS/FFS2 issues.) > > I just wanted to get on with my day and not have any fuss, so I > issued an "fdisk -iy sd1" command on the way to disklabel'ing > things. I suspect that's my error, because fdisk says this: (I've > added some commas to make for easier reading.) > > # fdisk sd1 > Disk: sd1 geometry: 364801/255/63 [1,565,565,872 Sectors] > Offset: 0 Signature: 0xAA55 > Starting Ending LBA Info: > #: id C H S - C H S [ start:size ] > --- > 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > *3: A6 0 1 2 - 97451 165 59 [ 64: 1,565,560,705 > ] OpenBSD > > Uhm, that doesn't seem right, considering the fdisk output for a > 1.5TB drive looks like this: > > # fdisk wd0 > Disk: wd0 geometry: 182401/255/63 [2,930,277,168 Sectors] > Offset: 0 Signature: 0xAA55 > Starting Ending LBA Info: > #: id C H S - C H S [ start:size ] > --- > 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > *3: A6 0 1 2 - 182400 254 63 [ 64: 2,930,272,001 > ] OpenBSD > > A drive with half the capacity seems to have double the numbers, but > not for geometry. I suspect that fdisk is lying to me, but I could > be wrong. > > Let's see what disklabel(8) has to say. On the 1.5TB drive, it > looks mostly like this (I've snipped some irrelevant partition data > and added commas to make big numbers easier to read): > > # disklabel wd0 > # /dev/rwd0c: > type: ESDI > disk: ESDI/IDE disk > label: ST31500341AS > duid: dded65e423b05de7 > flags: > bytes/sector: 512 > sectors/track: 63 > tracks/cylinder: 255 > sectors/cylinder: 16065 > cylinders: 182401 > total sectors: 2,930,277,168 > boundstart: 64 > boundend: 2930272065 > drivedata: 0 > > 16 partitions: (snipped) > #size offset fstype [fsize bsize cpg] > c: 2,930,277,1680 unused > > On the new 3TB drive, it looks like this: > > # disklabel sd1 > # /dev/rsd1c: > type: SCSI > disk: SCSI disk > label: ST3000DM001-9YN1 > duid: > flags: > bytes/sector: 512 > sectors/track: 63 > tracks/cylinder: 255 > sectors/cylinder: 16065 > cylinders: 364801 > total sectors: 5,860,533,168 > boundstart: 64 > boundend: 1565560769 > drivedata: 0 > > 16 partitions: > #size offset fstype [fsize bsize cpg] > c: 5,860,533,1680 unused > > Wait a minute here... disklabel seems to have correct data (ignoring > the duid). I'll bet
Re: Large (3TB) HDD support
On 6/1/2012 10:04 AM, Scott McEachern wrote: Hello everyone, I'm hoping that I'm missing something simple (like usual) and maybe someone could straighten me out. I'm trying to add a pair of 3TB drives to my workstation, which I plan on turning into a ~3TB RAID 1 array, and seem to be having difficulty realizing the full size of the drives. http://www.openbsd.org/faq/faq14.html#LargeDrive I don't have any experience using disks this large in OpenBSD, but ye olde fine print: "Note that not all controllers and drivers support large disks. For example, ami(4) has a limit of 2TB per logical volume. Always be aware of what was available when a controler or interface was manufactured, and don't just rely on "the connectors fit"." However, it's far from hopeless, yet...
Large (3TB) HDD support
Hello everyone, I'm hoping that I'm missing something simple (like usual) and maybe someone could straighten me out. I'm trying to add a pair of 3TB drives to my workstation, which I plan on turning into a ~3TB RAID 1 array, and seem to be having difficulty realizing the full size of the drives. The hardware is about a year old, and less than two years old according to the BIOS date: bios0: vendor American Megatrends Inc. version "2103" date 06/18/2010 bios0: ASUSTeK Computer INC. M4A785TD-V EVO (Correction, I've since updated the BIOS to the latest version, just in case, and it reads like so: bios0: vendor American Megatrends Inc. version "2105" date 07/23/2010 and it makes no difference.) (The full dmesg is below, but for now I'll just post the relevant bits.) The BIOS happily reports the two drives as present and of 3.0TB capacity. OpenBSD seems to recognize this as well: sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct fixed naa.50014ee001cbd923 sd0: 476940MB, 512 bytes/sector, 976773168 sectors sd1 at scsibus0 targ 1 lun 0: SCSI3 0/direct fixed naa.5000c5004a6e56f1 sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors sd2 at scsibus0 targ 2 lun 0: SCSI3 0/direct fixed naa.5000c5004a5baa2e sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors (Note that sd0 is my boot/OS drive, and works just fine. The two 3TB drives, sd1 and sd2, will eventually just be used for storage.) Those numbers look correct, like the OS is properly recognizing the capacity. I have a 1.5TB drive in another machine (a six year-old Pentium 4 no less!) that works fine and looks like this: wd0: 16-sector PIO, LBA48, 1430799MB, 2930277168 sectors (Although I should mention that that drive has a couple of <1TB partitions, so there are no FFS/FFS2 issues.) I just wanted to get on with my day and not have any fuss, so I issued an "fdisk -iy sd1" command on the way to disklabel'ing things. I suspect that's my error, because fdisk says this: (I've added some commas to make for easier reading.) # fdisk sd1 Disk: sd1 geometry: 364801/255/63 [1,565,565,872 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 1 2 - 97451 165 59 [ 64: 1,565,560,705 ] OpenBSD Uhm, that doesn't seem right, considering the fdisk output for a 1.5TB drive looks like this: # fdisk wd0 Disk: wd0 geometry: 182401/255/63 [2,930,277,168 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 1 2 - 182400 254 63 [ 64: 2,930,272,001 ] OpenBSD A drive with half the capacity seems to have double the numbers, but not for geometry. I suspect that fdisk is lying to me, but I could be wrong. Let's see what disklabel(8) has to say. On the 1.5TB drive, it looks mostly like this (I've snipped some irrelevant partition data and added commas to make big numbers easier to read): # disklabel wd0 # /dev/rwd0c: type: ESDI disk: ESDI/IDE disk label: ST31500341AS duid: dded65e423b05de7 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 182401 total sectors: 2,930,277,168 boundstart: 64 boundend: 2930272065 drivedata: 0 16 partitions: (snipped) #size offset fstype [fsize bsize cpg] c: 2,930,277,1680 unused On the new 3TB drive, it looks like this: # disklabel sd1 # /dev/rsd1c: type: SCSI disk: SCSI disk label: ST3000DM001-9YN1 duid: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 364801 total sectors: 5,860,533,168 boundstart: 64 boundend: 1565560769 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] c: 5,860,533,1680 unused Wait a minute here... disklabel seems to have correct data (ignoring the duid). I'll bet I'm failing at grade four math, but that looks roughly like a 3TB drive. So while I'm wondering about going back to grade school, I try creating one big partition on the new 3TB drive, and it goes like this: # disklabel -E sd1 Label editor (enter '?' for help at any prompt) > p g OpenBSD
Re: Idea for apmd
On Thu, May 31, 2012 at 11:21:20PM +, Stuart Henderson wrote: > On 2012-05-31, Ted Unangst wrote: > > On Thu, May 31, 2012 at 08:28, Tomas Bodzar wrote: > >> On Thu, May 31, 2012 at 3:45 AM, Juan Francisco Cantero Hurtado > >> wrote: > > > >>> This is important because when I open a web page with a lot of > >>> javascript, the browser is very slow. Also when I compile something with > >>> "make -j1", apmd doesn't raise the speed of my CPU, I need use "make > >>> -j4" for raising the cpu speed to 2700Mhz. > >> > >> What shows top, vmstat, systat about %sys, %usr, %idle during that > >> time? Because you can have 800MHz of CPU, but %usr and/or %sys can be > >> eg. only 20% so there's no reason to switch to higher frequency. > > > > apmd scaling works like crap with more than one cpu. This was fixed, > > then unfixed, but you can get the code from cvs if you like. > > > > > > conflicts. if anyone wants it they could grab it from junkpile.org/apmd.diff Thanks for the patch! I've been using the version 1.51 of apmd.c since yesterday. I can feel the difference with respect to the last version of apmd. Is it possible to add a new option to apmd for to select between the new and the old code?. I mean, eg: -C for use the "new" code with better SMP support and -O for "compatibility mode" with the old code for people with problematic machines. Cheers. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: AMD Zacate E350 (ASUS E35M1-M) dmesg/experiences?
2012/6/1 Manolis Tzanidakis : > The most obvious is that NAND flash devices have shorter lifespan than > hard disks. So how many flash drives have you broken?
Re: AMD Zacate E350 (ASUS E35M1-M) dmesg/experiences?
On 1 June 2012 17:11, Manolis Tzanidakis wrote:
> On Fri (01/06/12), Eugene Yunak wrote:
>> On 1 June 2012 13:49, Manolis Tzanidakis wrote:
>> > A raid on USB devices is not a good idea for a whole lot of other
>> > reasons though.
>>
>> Oh you are obviously such a seasoned OpenBSD expert, please tell us
>> more about your USB RAID experience and why it is a bad idea.
>
> The most obvious is that NAND flash devices have shorter lifespan than
> hard disks. Imagine wearing out both devices simultaneously with the
> RAID-1.
> I think it's better to have a USB stick for /, /usr and dump&restore or
> rsync it to the 2nd stick for redundancy. You should repeat this on
> updates. You should keep /var, /usr/{obj,ports,src}, /home and any other
> fs with frequent writes on the hard disks to extend the life of the USB
> stick.
>
Thank you for sharing your wisdom, now i know what i *should do*, you
made it pretty clear. Have you considered three-way mirror? What do
you think about mounting filesystems read-only? Have you heard of NFS
and remote syslog? I'm sure you will grant us the mercy of knowing why
all these are not a good idea.
>> It would be great if you could also go into deeper detail about / on
>> softraid - you must be the first one to mention it here on misc and
>> i'm sure everyone reading this is eager to learn how to make it work.
>
> I guess Stuart covered this on this thread. You should also read this:
> http://undeadly.org/cgi?action=article&sid=20111002154251
>
Oh yes Stuart knows what he's talking about.
Re: AMD Zacate E350 (ASUS E35M1-M) dmesg/experiences?
On Fri (01/06/12), Stuart Henderson wrote: > On 2012-06-01, Manolis Tzanidakis wrote: > > The basic idea is to have a small 'a' slice for the kernel on each > > disk and a 'd' (or whatever) for the raid. > > installboot(8) does the right thing automatically these days. > > At least on amd64 you don't need a special partition for the kernel. I didn't know about that. I guess the FAQ needs a softraid(4) section sooner or later. I should shut up and write it but spare time is a luxury for me right now. Anyone else? -- Manolis Tzanidakis http://mtzanidakis.com/ mtzanidakis[at]gmail[dot]com
Re: AMD Zacate E350 (ASUS E35M1-M) dmesg/experiences?
On Fri (01/06/12), Eugene Yunak wrote:
> On 1 June 2012 13:49, Manolis Tzanidakis wrote:
> > Nowadays it does. My server's / is on a softraid(4) RAID-1 array.
> > The basic idea is to have a small 'a' slice for the kernel on each
> > disk and a 'd' (or whatever) for the raid.
> > installboot(8) does the right thing automatically these days.
> > I think there is an article on undeadly with more detailed instructions
> > / explanations.
> >
> > A raid on USB devices is not a good idea for a whole lot of other
> > reasons though.
>
> Oh you are obviously such a seasoned OpenBSD expert, please tell us
> more about your USB RAID experience and why it is a bad idea.
The most obvious is that NAND flash devices have shorter lifespan than
hard disks. Imagine wearing out both devices simultaneously with the
RAID-1.
I think it's better to have a USB stick for /, /usr and dump&restore or
rsync it to the 2nd stick for redundancy. You should repeat this on
updates. You should keep /var, /usr/{obj,ports,src}, /home and any other
fs with frequent writes on the hard disks to extend the life of the USB
stick.
> It would be great if you could also go into deeper detail about / on
> softraid - you must be the first one to mention it here on misc and
> i'm sure everyone reading this is eager to learn how to make it work.
I guess Stuart covered this on this thread. You should also read this:
http://undeadly.org/cgi?action=article&sid=20111002154251
--
Manolis Tzanidakis
http://mtzanidakis.com/
mtzanidakis[at]gmail[dot]com
Re: AMD Zacate E350 (ASUS E35M1-M) dmesg/experiences?
On 1 June 2012 13:49, Manolis Tzanidakis wrote: > > On Fri (01/06/12), Marc Peters wrote: > > Be aware, that OpenBSD cannot boot from softraid. / needs to be on a > > single disk, but can be automatically backuped to an altroot device. > > Nowadays it does. My server's / is on a softraid(4) RAID-1 array. > The basic idea is to have a small 'a' slice for the kernel on each > disk and a 'd' (or whatever) for the raid. > installboot(8) does the right thing automatically these days. > > I think there is an article on undeadly with more detailed instructions > / explanations. > > A raid on USB devices is not a good idea for a whole lot of other > reasons though. > > -- > Manolis Tzanidakis > http://mtzanidakis.com/ > mtzanidakis[at]gmail[dot]com > Oh you are obviously such a seasoned OpenBSD expert, please tell us more about your USB RAID experience and why it is a bad idea. It would be great if you could also go into deeper detail about / on softraid - you must be the first one to mention it here on misc and i'm sure everyone reading this is eager to learn how to make it work. Best regards
Re: AMD Zacate E350 (ASUS E35M1-M) dmesg/experiences?
On 2012-06-01, Manolis Tzanidakis wrote: > On Fri (01/06/12), Marc Peters wrote: >> Be aware, that OpenBSD cannot boot from softraid. / needs to be on a >> single disk, but can be automatically backuped to an altroot device. > > Nowadays it does. My server's / is on a softraid(4) RAID-1 array. This is arch dependent. > The basic idea is to have a small 'a' slice for the kernel on each > disk and a 'd' (or whatever) for the raid. > installboot(8) does the right thing automatically these days. At least on amd64 you don't need a special partition for the kernel. - Shell out of the installer. - sh /dev/MAKEDEV sd1 (etc). - Create the RAID partition on the physical disks, you don't need another partition there. - Use bioctl to create the softraid. - Run the installer normally and choose the softraid disk as the install destination. > I think there is an article on undeadly with more detailed instructions > / explanations. > > A raid on USB devices is not a good idea for a whole lot of other > reasons though. > yeah. might be useful in testing but I agree.
Re: Unresponsive -current + rtorrent
On Fri, Jun 01, 2012 at 09:53:37AM +0200, David Coppa wrote: > > Yes, this is something I've also noticed. > No, I don't know how to patch it up. > In other words, please be my guest and help me in trying to debug this > problem... OK, will try to make some tests this weekend. Thank you.
Re: AMD Zacate E350 (ASUS E35M1-M) dmesg/experiences?
On Fri (01/06/12), Marc Peters wrote: > Be aware, that OpenBSD cannot boot from softraid. / needs to be on a > single disk, but can be automatically backuped to an altroot device. Nowadays it does. My server's / is on a softraid(4) RAID-1 array. The basic idea is to have a small 'a' slice for the kernel on each disk and a 'd' (or whatever) for the raid. installboot(8) does the right thing automatically these days. I think there is an article on undeadly with more detailed instructions / explanations. A raid on USB devices is not a good idea for a whole lot of other reasons though. -- Manolis Tzanidakis http://mtzanidakis.com/ mtzanidakis[at]gmail[dot]com
Plast 2012
[IMAGE] Grande successo di i-Man Interactive Manufacturing a PLAST 2012 [IMAGE] I numerosi visitatori al nostro stand hanno potuto apprezzare le funzionalitC di i-Man: * acquisire in tempo reale le stampate e lo stato della pressa * coadiuvare gli operatori ad eseguire i controlli qualitC * gestire gli stampi * visualizzare disegni e immagini dei prodotti * stampare ogni tipo di etichetta e ProdWare: l'ERP per le aziende di produzione. Se non vi C( stato possibile venirci a trovare in fiera e siete interessati a degli approfondimenti contattateci per un incontro! Logo ProdWare Elabora S.r.l. Software solutions & consulting for enterprise management Tel. 02-90.93.11 mail: elab...@prodware.it sito web: www.prodware.it Powered by: Scriba Disclaimer: Questa comunicazione e' stata inviata in conformita' alle norme vigenti in materia di tutela della privacy, d.lgs. 196/2003. Se desidera cancellare il suo nominativo, puo' rispondere a questa mail indicando nell'oggetto la parola "rimuovi".
Re: AMD Zacate E350 (ASUS E35M1-M) dmesg/experiences?
On 05/31/2012 05:54 PM, Manolis Tzanidakis wrote: > Please reply on the list. I'm already subscribed and others might find > your questions useful. Also, don't send HTML e-mails. Check the lists' > guidelines. > > On Thu (31/05/12), Eugene Yunak wrote: >> Thank you very much, this is super helpful! i am going to buy either >> this board or the E450 one and dmesg is precisely what i needed. >> >> One question if i may - do you know if it supports boot from USB and >> maybe USB raid 1? (i want to create mirror of usb sticks and install OS >> there, and use all the sata ports for data hdds). > > It boots from USB. I installed OBSD this way. I suppose softraid(4) > should support raid 1 with USB drives/sticks. I don't think it's a good > idea though. > Be aware, that OpenBSD cannot boot from softraid. / needs to be on a single disk, but can be automatically backuped to an altroot device. Here is my fstab in a similar setup: ~ $ more /etc/fstab /dev/sd0a / ffs rw 1 1 /dev/sd0b none swap sw aad9c166558b757e.d /usr ffs rw,nodev,softdep 1 2 aad9c166558b757e.e /tmp ffs rw,nodev,nosuid,softdep 1 2 aad9c166558b757e.f /home ffs rw,nodev,nosuid,softdep 1 2 aad9c166558b757e.g /var ffs rw,nodev,nosuid,softdep 1 2 /dev/sd1a /altroot ffs xx 0 0 hth, marc
Paga $880 solo por hoy SAMSUNG PL120
Si no podes visualizar este mail, ingresa a: http://news1.bonuscupon.com.ar/r.html?uid=1.p.29hh.e9.a161h5ucn8
Re: Unresponsive -current + rtorrent
On Fri, Jun 1, 2012 at 4:47 AM, Daniel Bolgheroni wrote: > Hi misc@, > > Running the latest snapshot, there are some issues I'm facing when I run > rtorrent + ~5 downloads. > > The system becomes VERY unresponsive, varying between 5 seconds of activity > and 10 seconds locked. Yes, this is something I've also noticed. No, I don't know how to patch it up. In other words, please be my guest and help me in trying to debug this problem... ciao David
