New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
10 mbit limitation doesn't matter to me, since I only have 9mbit/1mbit :P
love their services so far
So.. it takes 95 days to upload/download the 10 TB? I guess they have lots of extra storage space for whatever reason but don't want to dedicate all the bandwidth for so many users.
I don't think OVH has any scarcity of bandwidth (giving 100 Mbit unmetered with every 8 EUR dedi). More like, to be able to offer so much storage for cheap, they are using RAID configuration which isn't capable of high concurrent IOPS, such as a large disk count RAID6, maybe even with low-RPM drives to save on power and cooling. This won't be fast if many users are reading from and writing to the same array. So rather than having it just be randomly "slow" for everyone, they put a fixed cap trying to make sure the performance is at least predictable and consistent.
I wonder though if anyone at OVH questioned the insanity of this while they were planning it. Seems more like something to buy for bragging rights and / or low usage.
No, to get subsidized by the french government as local cloud business - Millions of Euros towards OVH each year (partly cash, partly in less tax) for the next 5-10 years.
It does not matter if it is profitable at all.
If you want to setup HubiC to work with your VPS or PC you may want to see https://forums.hubic.com/showthread.php?272-hubiC-for-Linux-beta-2-is-out-!
Openswift isn't even RAID. It is a replicated object storage using a ring topology. When you request an object from the cluster, the endpoint proxy will fetch it from one of the replicas in the ring. Given that design, it's not going to be high IOPs. The first rate limit is going to be how many endpoints they want to stick on the ring to serve access.
However, sticking 100Mbit unmetered on a server is very different than sticking 100Mbit unmetered on a backup server - at least from perspective of capacity planning.
On the lowest level data is still likely stored on a RAID of some sort. And in the end you're still reading bytes from a set of spinning magnetic disks, not "fetching objects" from a "ring topology". In other words, cut the crap and don't let the "cloud" b/s cloud your thinking.
Well, you were using RAID as a technical term and giving RAID6 as an example. Expand it however you like to encompass everything in the known world after the fact. But the fact of the matter is, its a network bandwidth issue, not a spindle one. The "cloud" b/s ring topology means that UNLIKE a humungous RAID6, concurrent accesses to the cluster is distributed to only those nodes that house a replica of the objects requested. There is no re-encoding of parity across the entire RAID. Instead, writes return success when written to TWO of three replica locations. This scales far better than RAID6, RAID60, RAID 600000000 ever could regardless of whether you think the term cloud itself is hyped.
You brought a lot of assumptions on the performance limitations of how arrays work to a different architecture. I point out that the assumptions are wrong, and I'd side more with perennate's conclusion.
Those are layers of abstraction @rm_ and just because you choose to call it crap, doesn't mean it's not architected and accessed differently....
/me ducks
EDIT: typo
Correct, and I was talking about the lowest level of how the data is actually stored (i.e. not in the fastest-performing manner). If you want to make a point that the bottleneck actually lies elsewhere (i.e. higher), sure, but opening with "Openswift is not even RAID" (...okay?), is a rather clumsy way to get that point across.
@rm_ from https://swiftstack.com/openstack-swift/architecture/
"Desired I/O performance for single-threaded requests should be kept in mind. This system does not use RAID, so each request for an object is handled by a single disk. Disk performance impacts single-threaded response rates."
It's JBOD with a higher layer co-ordinating writes - rather than RAID.
So the statement "Openswift is not even RAID" seems a fair statement of fact.
OVH's addition of OAuth pretty much renders this incompatible with everything Swift-compatible. But even then, I'm not sure I'd trust OVH with my backups since there's no way (that I know of) to test the integrity without a full restore.
Ya, that was surprising. I've seen the proxy-gateways now and even a fork of the python-cloudfiles
https://github.com/Gu1/python-cloudfiles-hubic
Still, i get ya. It'd be nice if they ran their own swift compatible auth.api proxy for this.
Is there any other way to verify?
- serious question actually.
Of course - you don't need to restore 100% of your backup to test its integrity. Just verify some random samples from it, e.g. 1-5% of total size. Same reason many factories don't run 100% of their product through full QA, testing a small set of random samples can be enough.
Linux app still fails majorly... this is annoying.
root@storage02:/zfs/x# hubic login --exclude=/zfs/x/_new/ --password_path=/etc/hubic.pass [email protected] /zfs/x/
[Error] no container named default found on remote account.
Command failed: System.InvalidOperationException: Cannot log in.
just login to my account
"
Please renew your password if you want to enjoy the latest hubiC features.
"
lol
Pour une poignée de dollars
Page temporairement indisponible
Seems like hubic died nothing is working anymore not even the login.
edit: Following an incident on a switch, access to hubiC is has been seriously impaired.
They said the data is safe in 3 different datacenters and hubic will "never" go down and now? a switch died oh yes.
Yup just seen a connection error flash up
Their official response is:
We will deploy a patch to increase significantly the ability of authentication servers. Intervention is planned for the evening of 18/03/14.
Transfers from NY datacenter or Florida are very slow to OVH (Hubic). I tested 2 days ago. Not worth I guess from Americas.
Someone must write a frontend for load balancing between multiple free hubic accounts
too bad that they dont accept paypal , pretty sad for meh
Wrote a short article on how to sync Dropbox and Hubic via a server: http://blog.droidzone.in/2014/03/22/synchronizing-dropbox-files-with-hubic/
I am now getting a much higher speed uploading to Hubic via hubicfuse. Couple of weeks ago I had 100 KB/sec, now it varies between 3 and 6 MB/sec (latter being the maximum of my internet upload speed). The IP which is being connected to, is also different (92.222.241.131). This is all on the free plan. Does anyone have an active subscription to confirm if your speed has improved too?
I'm seeing upload speeds varying between 10 and 125Mb/s.
Nice, time for me to give them a try.
they do? I've used paypal for services there atleast..
faster from here too. Now this service is getting quite interesting, i just have to test the solution @joelgm suggested to access it via bash script.