S3ForMe

Each file is stored at 3 different servers at the same time. Hot files are moved to RAM automatically and will be served very fast without even touching the disks. Our tests shows that each servers group has about 500Mb/s free bandwidth capacity at this time. And it can be increased to several Tb/s in a matter of days if needed. Additional servers will be added in 2-3 days do the server group if necessary.

Right now it is $0.04 per GB which is 3 times cheaper than Amazon and customers with a lot of traffic will get additional discounts.

1) I've made a typo, not "at least", but "at maximum", meaning that each server can store up to 5TB of data, it's 2x3TB hard drives servers. The density is very low because we use cheap hardware which fail regularly and such a small data amount means high recovery speed. 5TB is a soft limit and can be different for server groups, but it is not at the moment. Each group of 3 servers has a total capacity of 5TB because data is mirrored.

2) We have a centralised replicated metadata layer which is stored on the same servers as the data itself. All object chunks are stored at one servers group at the same time, so there is no need to connect to multiple servers to serve a file, it is enough to connect to one server from server group to get all the data. Metadata may be stored at different server group though. All chunks are replicated to 3 servers at the same time using a sequential append-only log to ensure that all servers has the same data. This may introduce replication lag and if it is too big for some server then it is removed from the server group until replication lag back to normal (1-3 seconds usually).

Actually, it is much simpler than I explained, data layer with replication, data consistency and sharding is completely transparent to the application layer and it is really-really small and simple. Email me at support@s3for.me and I'll share with you software details and you will understand how simple it is.

'AWSAccessKeyId' is part of XML Schema and can not be changed. You are right regarding AWS text in error messages, I removed it, thank you for noticing this.

This was the first thought - to take an open source S3 REST API clone, install it on Hetzner servers and work this way, but it is not the case. Any of the available solutions fit to us for different reasons. All core software is build by our team. We use Open Source software a lot, but the core of S3For.Me was developed from the first to the last line by our team.

I've checked Salesforce site and do not see anything similar to our logo. It will be replaced in the nearest future anyway.

These headers are part of S3 implementation an we left them to avoid any possible problems with S3 clients. Some clients are very strict on protocol validation and refused to work in some cases. The purpose of these headers are to track all requests and be able to find any problems with any particular request. You must include them when contacting support with problems with some request. This is true both for Amazon and S3For.Me

Our prices will aways be lower than Amazon S3, I can tell this for sure. But our main advantage is support - you can always open a ticket and get an answer on your question within 24 hours, but usually much faster.

Yes, of course we have our reasons. One of the most important are: - We didn't like internal storage implementation, we believe that we can do better. Very self-confident, I know, but I still think so after almost a year of development and production use. - Production deployment from the start required a lot of hardware investments, we decided to put these investments into development.

Personally I think that we made a right choice and I don't regret about it. We learned a lot about cloud storage, scalability, performance, possible problems and I believe that this knowledge is very important for every team who works in cloud storage business.

I'll ask guy who made this design about stock images service.

We use this URL to monitor service uptime: http://rest.s3for.me/check/test.html

AWS stand nothing for our company, we don't use this acronym, but for Amazon it stands for "Amazon Web Services".

Here is our public status check: http://host-tracker.com/website-uptime-statistics/11891746/l...

> How does data placement work? Each object bigger than some size is split in small parts, these parts are linked to the metadata object with all information, such as name, bucket, size, date, checksum, etc. All data is split in server groups - each group is at least 3 mirrored servers with no more than 5TB of data to make system flexible. Server groups can be added to increase system capacity or removed to decrease.

> How is data checked for correctness? With checksum. Once the data is uploaded by user he will receive its checksum and must compared it with local checksum to make sure that it was correctly transfered and stored. The same checksum is used to ensure server-side data correctness.

> How do you do listings at scale? There is a trick - we support only one delimiter (/), this means that we can use very simple listing algorithm which scales very easy.

> During hardware failures, do you still make any durability or availability guarantees? Yes, all data is split in server groups by 3 servers each. If one of 3 servers will fail, this group will still running like nothing happened, some running requests may fail though. If 2 servers will fail at the same time, then this group and all data in it will be put in read-only mode to avoid any possible data damage.

> How do you handle hot content? It is cached in RAM by OS, we do not perform any additional measures. OS does a pretty good job.

> How do you resolve conflicts (eg concurrent writes)? Some conflicts are resolved by the software if possible. Unrecoverable conflicts are returned back to user with HTTP 400, 500 errors to make him know that something is wrong and he must run request again. For concurrent writes we use simple rule - the last one wins.

Current design was build by developers, not designers and will be renewed once the professional design is ready. We put all our efforts on backend and storage subsystem development and completely forgot about our temporary public website. Site images were taken from various public stock image services, I hope we didn't violate any rights by using these images.

No, actually it is much cheaper, €2/TB means $0.0026/GB

API is the same as Amazon S3, you can find documentation here: http://docs.aws.amazon.com/AmazonS3/latest/API/APIRest.html

I agree, maybe you can suggest a good name for it?

Backend is much better, but the public site must be redesigned, it is awful, I agree.

Personally I can't understand why Amazon S3 is so expensive!

No, we use self-written software, this means that we can fix any issue or add additionally functionality very fast and do not depend on any vendor.

S3 means "Storage Should be Simple" in our case :-) No one has ever contacted us regarding this.

Our marketing guys said that it is a good idea :-)

Absolutely not. edit: I meant that we do not disclose any user-related data to anyone without a court order.

We are using our own self-written software to implement S3 protocol. We do not support all enterprise-features like extended ACL, regions, encryption, this makes our software much simpler and easier to develop. You can find basic documentation here https://my.s3for.me/client/docs/index, all the rest documentation can be found at Amazon S3 documentation site, it is basically the same with small differences. Edit: can't post comments for some time (You're submitting too fast...), will reply later.

Or datacenter is located at Germany