hard limit of 500 gb for free hosting?

bobdavcav98

Member
Messages
129
Reaction score
0
Points
16
Or rather, 500,000 MB which is actually about 489 GB. What does everyone think of this? It seems to be already the defacto limit, so why not make it official? Or how about raising the limit of files to be automatically deleted to 16 mb and the disk space limit to 800,000 MB? The reason I suggest 16 mb is I saw on the plan comparison page that the maximum size of a file uploaded via PHP script is 16 mb.
 

essellar

Community Advocate
Community Support
Messages
3,295
Reaction score
227
Points
63
You're calculating that by multiplying the inode limit by the file size limit. What about databases? They can store rather a lot of data, and don't count against the inode count (at least not in a signifcant way); the amount of data you can store is not the same as the number of maxed-out files you can store. And the file size limit is more about restricting the kinds of files likely to be stored than the amount of space they're likely to take up; you may have very good reasons for uploading something larger than you can keep around.
 

caftpx10

Well-Known Member
Messages
1,534
Reaction score
114
Points
63
I would like to point out that having 500GB of storage allocated for your account is not considered a hard limit, unless your site were to easily use up all of that space.
 

bobdavcav98

Member
Messages
129
Reaction score
0
Points
16
And the file size limit is more about restricting the kinds of files likely to be stored than the amount of space they're likely to take up; you may have very good reasons for uploading something larger than you can keep around.
Which is why I don't like the limit as it currently stands. Good point about databases, didn't really think about that.
I would like to point out that having 500GB of storage allocated for your account is not considered a hard limit, unless your site were to easily use up all of that space.
Good point, but the same could be said about the number of files as well. Even with moving my primary email account here, I'm nowhere close to the 50,000 file limit, and am not even at half my allocated storage space yet.
 

caftpx10

Well-Known Member
Messages
1,534
Reaction score
114
Points
63
Good point, but the same could be said about the number of files as well. Even with moving my primary email account here, I'm nowhere close to the 50,000 file limit, and am not even at half my allocated storage space yet.
Inodes are way more strict with what's there as of now.
They can count towards the cPanel files and if you install something like a CMS, a lot of it would be used right away.
Thing is that it's there to prevent a slow down to do with indexing, it's like having a large amount of files and folders in one place, it will be a lot more slower than when you have way less.
 

essellar

Community Advocate
Community Support
Messages
3,295
Reaction score
227
Points
63
Email, traditionally, is not an archive. I know that Gmail forced a bit of a perspective change on what an email service is - it can act essentially as a searchable file repository - but the purpose of your account is to host a web site, not to store email.
 

bobdavcav98

Member
Messages
129
Reaction score
0
Points
16
Yeah, I have a website running WordPress and one email account. With that, I think I'm getting close to 4,000 files, will check again next time I actually log into CPannel.
 

essellar

Community Advocate
Community Support
Messages
3,295
Reaction score
227
Points
63
WordPress is kind of horrible that way. I understand why they have the files broken out that way for development and maintenance, but they really ought to have a "make" process for installation instances - they can easily reduce the number of files (and the includes that include includes that include includes...) by 80-90%, speeding everything up tremendously without otherwise affecting functionality at all. (Yes, it would mean having code duplicated in some places in the installation instance, but the extra disk space required would be essentially meaningless by today's standards - we're not talking about 100MB hard drives anymore - and the deeply-nested loads from disk, which take up most of the time outside of the database, would go away. And they'd still have DRY in development.)
 
Top