heh
:D
hello
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?
growing softraid is not currently supported
if you're wanting it to be supported learn to code c ;-) maybe also hope a developer gets to it before you learn c .. ;-)
ahah i learnt C a while back.. :D but i dont think i would be able to devlop that
hmm in your statement, do you mean that even a non-crypto softraid volume cant be grown?
correct
softraid metadata is highly dependent on the size of the chunks when created
i see
maybe you should convert to zfs ;)
understood.. now just not sure how to solve my problem besides destroying the fs and newfs-ing it..
ahha i did think of it. according to the faq, obsd do not support zfs.. didnt look if there are any patch/commit though
nope... openbsd does not support zfs
with fuse .. zfs-fuse might be an option if someone wished to port it
switch to fbsd!
lol
i tried fbsd a few times, but it seems to fail me always
then I can learn new ways to bash my head against the wall ;-)
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
heh
ports and packages are really poorly handled imho ..
in fbsd*
i never had any issue w pkg and/or ports in obsd.. building world etc. it just runs smooth
zfs-fuse in openbsd would probably be horrible slow
probably why exactly?
linux ha slinuxs linux uses zfs-fuse yes?
just a feeling :D i think fuse is not where highspeed filesystems should reside
openbsd is not built for speed
on the contrary, filesystems that allocate tons of memory belong in userland given that OpenBSD's kernel memory space is constrained
bottom line is, I'd expect the filesystem to not be a bottleneck but rather the disk io speeds instead
if the filesystem is slower due to running in userland vs kernel, the algorithm must be horribly inefficient
(or horribly cpu intensive by design)
well, I'll stick to my point of view until disproofed :)
now its bbq time
bbq time.. damn lucky. where're u based?
sweden
haha makes sense.. time for dinner there :P
well enjoy ;)
I just have a hard time buying an argument about speed when no real constructive reasons are given ;-)
now if there were actual testing done, hey all the better
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
:P
(it's actually an interesting paper now that I'm reading it)
up_the_irons ping
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/
rolled back meaning you guys removed the default card ending in 8888 and used an alternative card ending in 2906
emu:  support turnaround is usually within 24 hours,  but occasionally 48.
ok thanks will wait
jpalmer: it's usually quicker than that isn't it?
i suppose billing matters can be more complex
Also a lesser priority than downtime.
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.