[00:05] <mercutio> heh
[00:21] <GluffiS> :D
[00:21] *** nixbag has quit IRC (Ping timeout: 246 seconds)
[00:34] *** nixbag has joined #arpnetworks
[00:35] *** nixbag is now known as Guest48486
[00:56] *** Ehtyar has quit IRC (Quit: IRC is just multiplayer notepad)
[02:13] *** Guest48486 has quit IRC (Quit: leaving)
[02:15] *** nixbag has joined #arpnetworks
[02:21] *** ixokai_ has quit IRC (Read error: Connection reset by peer)
[02:22] *** ixokai_ has joined #arpnetworks
[02:28] *** HighJinx has quit IRC (Ping timeout: 245 seconds)
[02:31] *** HighJinx has joined #arpnetworks
[02:44] *** HighJinx has quit IRC (Ping timeout: 276 seconds)
[02:45] *** HighJinx has joined #arpnetworks
[02:51] *** first2know has quit IRC (Quit: Leaving)
[02:53] *** first2know has joined #arpnetworks
[03:04] *** vin\ has joined #arpnetworks
[03:08] *** vin\ has quit IRC (Client Quit)
[04:00] *** robonerd has quit IRC (Quit: zzz)
[04:37] *** cam13 has joined #arpnetworks
[04:37] <cam13> hello
[04:50] <cam13> anyone  knows whether i can resize my root softraidC parition (under obsd)? following the method http://scie.nti.st/2013/3/4/how-to-resize-an-openbsd-root-partition/ doesnt seem to work as I need to resize both wd0 but also but also the softraid0 disk mounted when performing bioctl. growfs gently tells me it only supports ffs :X I guess I am pretty stuck or is there any tips?
[07:34] *** ixokai_ has quit IRC (Read error: Connection reset by peer)
[07:35] <toddf> growing softraid is not currently supported
[07:35] *** ixokai_ has joined #arpnetworks
[07:35] *** ixokai_ has quit IRC (Changing host)
[07:35] *** ixokai_ has joined #arpnetworks
[07:37] <toddf> if you're wanting it to be supported learn to code c ;-) maybe also hope a developer gets to it before you learn c .. ;-)
[07:53] <cam13> ahah i learnt C a while back.. :D but i dont think i would be able to devlop that
[07:56] <cam13> hmm in your statement, do you mean that even a non-crypto softraid volume cant be grown?
[08:09] <toddf> correct
[08:09] <toddf> softraid metadata is highly dependent on the size of the chunks when created
[08:11] <cam13> i see
[08:12] <GluffiS> maybe you should convert to zfs ;)
[08:12] <cam13> understood.. now just not sure how to solve my problem besides destroying the fs and newfs-ing it..
[08:14] <cam13> ahha i did think of it. according to the faq, obsd do not support zfs.. didnt look if there are any patch/commit though
[08:16] <GluffiS> nope... openbsd does not support zfs
[08:47] *** ixokai__ has joined #arpnetworks
[08:47] *** ixokai__ has quit IRC (Changing host)
[08:47] *** ixokai__ has joined #arpnetworks
[08:50] *** ixokai_ has quit IRC (Ping timeout: 240 seconds)
[08:54] <toddf> with fuse .. zfs-fuse might be an option if someone wished to port it
[08:59] <milki> switch to fbsd!
[09:01] <cam13> lol
[09:01] <cam13> i tried fbsd a few times, but it seems to fail me always
[09:02] <toddf> then I can learn new ways to bash my head against the wall ;-)
[09:02] <toddf> seriously, its a rare thing these days, but I specalize in openbsd because I can focus and undertand everything there; if I start branching out I always end up being frustrated and wanting to port over openbsd's ports tree or whatever because it just works
[09:03] <staticsafe> heh
[09:03] <cam13> ports and packages are really poorly handled imho ..
[09:03] <cam13> in fbsd*
[09:03] <cam13> i never had any issue w pkg and/or ports in obsd.. building world etc. it just runs smooth
[09:10] <GluffiS> zfs-fuse in openbsd would probably be horrible slow
[09:11] <toddf> probably why exactly?
[09:11] <toddf> linux ha slinuxs linux uses zfs-fuse yes?
[09:11] <GluffiS> just a feeling :D i think fuse is not where highspeed filesystems should reside
[09:12] <GluffiS> openbsd is not built for speed
[09:12] <toddf> on the contrary, filesystems that allocate tons of memory belong in userland given that OpenBSD's kernel memory space is constrained
[09:13] <toddf> bottom line is, I'd expect the filesystem to not be a bottleneck but rather the disk io speeds instead
[09:13] <toddf> if the filesystem is slower due to running in userland vs kernel, the algorithm must be horribly inefficient
[09:13] <toddf> (or horribly cpu intensive by design)
[09:16] <GluffiS> well, I'll stick to my point of view until disproofed :)
[09:16] <GluffiS> now its bbq time
[09:19] <cam13> bbq time.. damn lucky. where're u based?
[09:20] <GluffiS> sweden
[09:25] <cam13> haha makes sense.. time for dinner there :P
[09:25] <cam13> well enjoy ;)
[09:29] <toddf> I just have a hard time buying an argument about speed when no real constructive reasons are given ;-)
[09:29] <toddf> now if there were actual testing done, hey all the better
[09:33] <brycec> FUSE file systems are typically slower than the refined and closely-tied-to-the-kernel file system implementations. Ergo it's reasonable to assume that zfs-fuse would perform slower than its native counterpart. Here's some research: http://www.csl.sri.com/users/gehani/papers/SAC-2010.FUSE.pdf
[09:33] <brycec> :P
[09:34] <brycec> (it's actually an interesting paper now that I'm reading it)
[10:10] *** toddf has quit IRC (Ping timeout: 246 seconds)
[10:11] *** toddf has joined #arpnetworks
[10:11] *** ChanServ sets mode: +o toddf
[10:13] *** robonerd has joined #arpnetworks
[10:28] *** robonerd has quit IRC (Quit: zzz)
[10:30] *** ixokai_ has joined #arpnetworks
[10:31] *** ixokai_ has quit IRC (Changing host)
[10:31] *** ixokai_ has joined #arpnetworks
[10:32] *** ixokai__ has quit IRC (Ping timeout: 240 seconds)
[12:31] *** lteo has quit IRC (Changing host)
[12:31] *** lteo has joined #arpnetworks
[13:17] *** nesta- has joined #arpnetworks
[13:20] *** staticsafe-znc has quit IRC (Ping timeout: 240 seconds)
[13:20] *** nesta has quit IRC (Ping timeout: 240 seconds)
[13:20] *** nesta- is now known as nesta
[13:20] *** ixokai__ has joined #arpnetworks
[13:20] *** ixokai_ has quit IRC (Ping timeout: 240 seconds)
[13:20] *** NiTeMaRe has quit IRC (Ping timeout: 240 seconds)
[13:20] *** ixokai__ has quit IRC (Changing host)
[13:20] *** ixokai__ has joined #arpnetworks
[13:21] *** staticsafe-znc has joined #arpnetworks
[13:21] *** NiTeMaRe has joined #arpnetworks
[13:49] <pjs> up_the_irons ping
[15:20] *** ixokai__ has quit IRC (Read error: Connection reset by peer)
[15:21] *** ixokai_ has joined #arpnetworks
[15:29] *** doomviki1g is now known as doomviking
[16:13] *** Ehtyar has joined #arpnetworks
[17:14] *** ixokai_ has quit IRC (Ping timeout: 240 seconds)
[17:49] *** emu has joined #arpnetworks
[17:50] <emu> Hi, who can i talk to about billing?  you guys suspended my vps about 4 months ago for recieving a ddos attack, you wanted me to promise it would not happen again which of course i cant.  i cancled the vps and moved hosts.  two days ago you charged a rolled back CC of 100.00.  ive gave support/billing a reasonable amount of time to respond. atleast 24 hours/
[17:57] <emu> rolled back meaning you guys removed the default card ending in 8888 and used an alternative card ending in 2906
[18:21] <jpalmer> emu:  support turnaround is usually within 24 hours,  but occasionally 48.
[18:34] <emu> ok thanks will wait
[18:47] *** emu has quit IRC (Quit: leaving)
[19:44] <mercutio> jpalmer: it's usually quicker than that isn't it?
[19:45] <mercutio> i suppose billing matters can be more complex
[19:47] <CaZe> Also a lesser priority than downtime.
[22:22] <brycec> Yeah, a bit of a sensitive/touchy subject... For all I know, maybe garry's busy trying to figure out what happened and it's taking some time.
[22:43] *** staticsafe-znc has quit IRC (Ping timeout: 240 seconds)
[22:44] *** Ehtyar has quit IRC (Ping timeout: 240 seconds)
[22:44] *** mike-burns has quit IRC (Ping timeout: 240 seconds)
[22:44] *** up_the_irons has quit IRC (Ping timeout: 240 seconds)
[22:58] *** staticsafe-znc has joined #arpnetworks
[22:58] *** Ehtyar has joined #arpnetworks
[22:58] *** up_the_irons has joined #arpnetworks
[22:58] *** ChanServ sets mode: +o up_the_irons
[23:01] *** mike-burns has joined #arpnetworks
[23:01] *** ChanServ sets mode: +o mike-burns
[23:04] *** mnathani has quit IRC (Ping timeout: 246 seconds)
[23:28] *** mnathani has joined #arpnetworks