Tony

This is the whole nature of web hosting and the varying usage patterns. You only say can fit 5 sites on your account another guy is using databases and had less files and fits 100. Then you have people who can't even run one site due to them receiving to much traffic or receiving or running too intensive programs. If everyone ran the same site and same program none of this would be a problem. That is unfortunately not the case and users rather have a one size fits all approach to web hosting when in reality it's not going to work. For the majority it does but people like you it does not since your usage patterns are not the norm. It's not about being dishonest or anything of that nature the reality is 1 million inodes or whatever the amount would cost more than the hosting plan. It would also cause problems for the shared environments as all the small files cause performance issues as well for various services.

This issue should now be fixed.

The network cable has been replaced we're going to continue to monitor the switch for errors in hopes that they have stopped. We'll update the ticket once we have further information.

Switching the port speed has not stopped the errors from being produced. We're now going to attempt to replace the network cable in hopes that it is in fact the cause of the issues. We will do this tonight between 11:00PM and 12:00AM CDT. There is a 1 hour window but most likely will be 30 minutes to handle everything. During the switch there will be several points of connection resets as we test the cable and switch it over to the server.

The server is now running on a 1gbit port to see if it's a problem with memory allocation for this specific machine which increasing the port speed will give it more memory on the switch. This seems highly unlikely to be the cause though as we have machines sending much more data and many more packets on other switches without issue. This is just part of troubleshooting the problem though to track down the cause. If this fails to resolve the issue then the next step will be to switch the ethernet cable in case it has gone bad.

We believe there could be a problem with the public network of the Mustang server. We've seen two small outages in the past 48 hours on the public network of this server for no apparent reason when looking at the server itself. We're seeing disregarded packets at the switch level which suggests there could be a problem causing not only network problems but potentially intermittent packet loss. We're working on tracking this down which could mean small periods of increased latency and or down time while we attempt to find the actual cause. We're sorry about any inconvenience this may cause.

Because the number of inodes on a system is limited. A single user in theory could fill an entire systems inodes if their allocation is space allocation is high enough and they make single 1 byte files. Then there are file system performance issues you can run into when dealing with many small tiny files. For most people 250,000 inodes is a lot of files and if they're running into such limits it typically means there is a problem. There is several issues you run into just with dealing with all these files. For one there are limitations on the number of files that can be in a directory which I believe is 32,000. Of course well before then you'll run into other issues like you won't even be able to browse inside a folder with that many files via ftp. SSH you can but it'll sure be slow bringing up that list of files. So for me I'm wondering if you actually had that many files for sites and if it wasn't just coming from somewhere else. A common problem people run into is they actually have a ton of files via mail accounts. So they turn on a catch-all and it ends up with 100,000 emails sitting there unread and growing every day.

Windows you use the command tracert so for example tracert avatarprime.net For ping you could do something like: ping -n 100 avatarprime.net Both commands are ran from cmd. You can route them to a txt file by doing cmd > c:\myfile.txt or wherever you want to save it.

The mustang server looks fine has about 70% CPU idle and 7.5GB of free memory. I visited your site and I get about 513ms to load the page and I'm about 70ms from the server itself. It sounds like some sort of routing issue between your ISP and the server. You're best to submit a ticket with a traceroute along with ping tests to check for packet loss. Also the number of domains on an IP means nothing. One user could add 100 parked domains and suddenly that's apparently 100 sites. I'd take that with a grain of salt as that's not how many user accounts is on an IP it's just the number of domains which with the fact you could park 100 domains makes the 1000 number meaningless.

Per account I suppose so a reseller could have more inodes spread across more cPanel accounts. This whole inodes limit thing came from providers doing cPanel backups. Since we use R1Soft it does not mean as much as we're just taking block changes. There are limits on the number of inodes a file system has but we've never encountered being close to such limits.

We will be updating the Phantom server kernel to the latest version on Thursday June 17th between 8:00am PDT and 11:00am PDT. We estimate this will result in about 10 minutes of down time while the server reboots. Even though we're running Ksplice to minimize reboots we like to do an update every time there is a major operating system update. In this case CentOS 5.5 was released so we'd like to run the latest 5.5 kernel to get any non security related improvements which Ksplice does not do as it's strictly for security updates. Date: 06/17/2010 Start time (PDT): 8:00am End time (PDT): 11:00am Duration: 3 hours Estimated Down Time: 10 minutes

We will be updating the Spitfire server kernel to the latest version on Friday June 18th between 8:00am PDT and 11:00am PDT. We estimate this will result in about 10 minutes of down time while the server reboots. Even though we're running Ksplice to minimize reboots we like to do an update every time there is a major operating system update. In this case CentOS 5.5 was released so we'd like to run the latest 5.5 kernel to get any non security related improvements which Ksplice does not do as it's strictly for security updates. Date: 06/18/2010 Start time (PDT): 8:00am End time (PDT): 11:00am Duration: 3 hours Estimated Down Time: 10 minutes

We will be updating the Titan server kernel to the latest version on Friday June 18th between 8:00am PDT and 11:00am PDT. We estimate this will result in about 10 minutes of down time while the server reboots. Even though we're running Ksplice to minimize reboots we like to do an update every time there is a major operating system update. In this case CentOS 5.5 was released so we'd like to run the latest 5.5 kernel to get any non security related improvements which Ksplice does not do as it's strictly for security updates. Date: 06/18/2010 Start time (PDT): 8:00am End time (PDT): 11:00am Duration: 3 hours Estimated Down Time: 10 minutes

We will be updating the Mustang server kernel to the latest version on Thursday June 17th between 9:00am CDT and 12:00pm CDT. We estimate this will result in about 10 minutes of down time while the server reboots. Even though we're running Ksplice to minimize reboots we like to do an update every time there is a major operating system update. In this case CentOS 5.5 was released so we'd like to run the latest 5.5 kernel to get any non security related improvements which Ksplice does not do as it's strictly for security updates. Date: 06/17/2010 Start time (CDT): 9:00am End time (CDT): 12:00pm Duration: 3 hours Estimated Down Time: 10 minutes

We will be updating the Mars server kernel to the latest version on Friday June 18th between 9:00am CDT and 12:00pm CDT. We estimate this will result in about 10 minutes of down time while the server reboots. Even though we're running Ksplice to minimize reboots we like to do an update every time there is a major operating system update. In this case CentOS 5.5 was released so we'd like to run the latest 5.5 kernel to get any non security related improvements which Ksplice does not do as it's strictly for security updates. Date: 06/18/2010 Start time (CDT): 9:00am End time (CDT): 12:00pm Duration: 3 hours Estimated Down Time: 10 minutes

We will be updating the Mars server kernel to the latest version on Friday June 18th between 9:00am CDT and 12:00pm CDT. We estimate this will result in about 10 minutes of down time while the server reboots. Even though we're running Ksplice to minimize reboots we like to do an update every time there is a major operating system update. In this case CentOS 5.5 was released so we'd like to run the latest 5.5 kernel to get any non security related improvements which Ksplice does not do as it's strictly for security updates. Date: 06/18/2010 Start time (CDT): 9:00am End time (CDT): 12:00pm Duration: 3 hours Estimated Down Time: 10 minutes

We will be updating the Skyline server kernel to the latest version on Friday June 18th between 9:00am CDT and 12:00pm CDT. We estimate this will result in about 10 minutes of down time while the server reboots. Even though we're running Ksplice to minimize reboots we like to do an update every time there is a major operating system update. In this case CentOS 5.5 was released so we'd like to run the latest 5.5 kernel to get any non security related improvements which Ksplice does not do as it's strictly for security updates. Date: 06/18/2010 Start time (CDT): 9:00am End time (CDT): 12:00pm Duration: 3 hours Estimated Down Time: 10 minutes

We will be updating the Saturn server kernel to the latest version on Friday June 18th between 9:00am CDT and 12:00pm CDT. We estimate this will result in about 10 minutes of down time while the server reboots. Even though we're running Ksplice to minimize reboots we like to do an update every time there is a major operating system update. In this case CentOS 5.5 was released so we'd like to run the latest 5.5 kernel to get any non security related improvements which Ksplice does not do as it's strictly for security updates. Date: 06/18/2010 Start time (CDT): 9:00am End time (CDT): 12:00pm Duration: 3 hours Estimated Down Time: 10 minutes

We will be updating the Venus server kernel to the latest version on Thursday June 17th between 9:00am EDT and 12:00pm EDT. We estimate this will result in about 10 minutes of down time while the server reboots. Even though we're running Ksplice to minimize reboots we like to do an update every time there is a major operating system update. In this case CentOS 5.5 was released so we'd like to run the latest 5.5 kernel to get any non security related improvements which Ksplice does not do as it's strictly for security updates. Date: 06/17/2010 Start time (EDT): 9:00am End time (EDT): 12:00pm Duration: 3 hours Estimated Down Time: 10 minutes

We will be updating the Neptune server kernel to the latest version on Thursday June 17th between 9:00am EDT and 12:00pm EDT. We estimate this will result in about 10 minutes of down time while the server reboots. Even though we're running Ksplice to minimize reboots we like to do an update every time there is a major operating system update. In this case CentOS 5.5 was released so we'd like to run the latest 5.5 kernel to get any non security related improvements which Ksplice does not do as it's strictly for security updates. Date: 06/17/2010 Start time (EDT): 9:00am End time (EDT): 12:00pm Duration: 3 hours Estimated Down Time: 10 minutes

We will be updating the Jupiter server kernel to the latest version on Thursday June 17th between 9:00am EDT and 12:00pm EDT. We estimate this will result in about 10 minutes of down time while the server reboots. Even though we're running Ksplice to minimize reboots we like to do an update every time there is a major operating system update. In this case CentOS 5.5 was released so we'd like to run the latest 5.5 kernel to get any non security related improvements which Ksplice does not do as it's strictly for security updates. Date: 06/17/2010 Start time (EDT): 9:00am End time (EDT): 12:00pm Duration: 3 hours Estimated Down Time: 10 minutes

The choice is right on the order form. It asks you location has has first available as an option if you have no preference then the other options are each location we offer that service in.

Lets just say it's 250,000 then a good round number. Above that we'd question what exactly an account is being used for if it has 250,000 different files and folders.

Should be fine then

You could run a file hosting service off a hosting account. Please keep in mind we don't tolerate these types of sites being used for illegal content.