Partition Max's out at 9x %
Brian Vienneau
I wonder how many people have this problem and have found solutions. I have
a webserver with millions and millions of html files and gifs. What seems to
happen is my disk will run out of space between 90% and 97%. I know it has
something to do with blocks/inodes and when we make new partitons we are
sometimes able to get around it by setting blocks per inode to a lower
number.
Does anyone else have this problem and how do they deal with after the fact,
meaning you have a partition full and you do not want to recreate and
transfer all the data.
Thanks,
Brian Vienneau
Nuvo Network Management
bvie...@nuvo.com
Anthony D. Ortenzi
"Brian Vienneau" <bvie...@nuvo.com>
> I have
> a webserver with millions and millions of html files and gifs. What seems
to
> happen is my disk will run out of space between 90% and 97%. I know it has
> something to do with blocks/inodes and when we make new partitons we are
> sometimes able to get around it by setting blocks per inode to a lower
> number.
>
> Does anyone else have this problem and how do they deal with after the
fact,
> meaning you have a partition full and you do not want to recreate and
> transfer all the data.
This problem is in no way specific to Sun, does not need to be crossposted
to 7 newsgroups, and you have found the answer already. Quit being cheap
and/or lazy, and repartition and/or purchase more disk. Disk is cheap, and
if you're bitching about not being able to go beyond 90% full, you are not
capable of making professionally mature decisions about systems
administration. Production systems with dynamic filesystems should never be
managed in this way.
-Anthony
Daeshik Kim
it has to be used all of them 100 % abosultely for some reason,
run 'man tunefs'.
"Anthony D. Ortenzi" <use...@litfire.com> wrote in message
news:RBn07.1162$zg4.1...@newsread2.prod.itd.earthlink.net...
Mathew Kirsch
> I wonder how many people have this problem and have found solutions. I have
> a webserver with millions and millions of html files and gifs. What seems to
> happen is my disk will run out of space between 90% and 97%. I know it has
> something to do with blocks/inodes and when we make new partitons we are
> sometimes able to get around it by setting blocks per inode to a lower
> number.
You've discovered both the cause of the problem, and the solution.
Each filesystem is cut up into smaller chunks called inodes. These are 4
kilobytes in size by default, IIRC. So, the minimum size of any file would be
4 kilobytes; even if the file is only 10 bytes long, it will take up 4
kilobytes of space on the disk.
If, for example, a filesystem has 1,000,000 4KB inodes, and you write
1,000,000 2KB files, your filesystem will be full, even though you only used
up 50% of the available space!
The solution is to PLAN AHEAD, and create the filesystem with
appropriately-sized inodes BEFORE you run into this problem. You can create
filesystems with 2K or 1K inodes, at the cost of a small amount of usable disk
space, and a minor performance degradation because of the extra overhead.
Normally, neither is noticeable.
> Does anyone else have this problem and how do they deal with after the fact,
> meaning you have a partition full and you do not want to recreate and
> transfer all the data.
If you find out after the fact, you're screwed if you absolutely, positively
must live by the rules you mention above. There is nothing you can do but live
with the fact that the filesystems are 90-97% full.
Jonathan Biggar
> > I wonder how many people have this problem and have found solutions. I have
> > a webserver with millions and millions of html files and gifs. What seems to
> > happen is my disk will run out of space between 90% and 97%. I know it has
> > something to do with blocks/inodes and when we make new partitons we are
> > sometimes able to get around it by setting blocks per inode to a lower
> > number.
>
> You've discovered both the cause of the problem, and the solution.
>
> Each filesystem is cut up into smaller chunks called inodes. These are 4
> kilobytes in size by default, IIRC. So, the minimum size of any file would be
> 4 kilobytes; even if the file is only 10 bytes long, it will take up 4
> kilobytes of space on the disk.
>
> If, for example, a filesystem has 1,000,000 4KB inodes, and you write
> 1,000,000 2KB files, your filesystem will be full, even though you only used
> up 50% of the available space!
>
> The solution is to PLAN AHEAD, and create the filesystem with
> appropriately-sized inodes BEFORE you run into this problem. You can create
> filesystems with 2K or 1K inodes, at the cost of a small amount of usable disk
> space, and a minor performance degradation because of the extra overhead.
> Normally, neither is noticeable.
Good advice, but wrong in the detail. Inodes are not the same thing as
block size. Each file or directory in the file system uses exactly one
inode, which is of a fixed size. When the filesystem is created, a
formula is used to determine the total number of inodes that are
preallocated in the filesystem. Once you use them all, you cannot
create any new files in that filesystem.
If you set the blocks per inode factor to a smaller number, you get more
space on the disk preallocated to inodes (which increases the maximum
number of files), at the expense of less space available for data
storage inside files.
> > Does anyone else have this problem and how do they deal with after the fact,
> > meaning you have a partition full and you do not want to recreate and
> > transfer all the data.
>
> If you find out after the fact, you're screwed if you absolutely, positively
> must live by the rules you mention above. There is nothing you can do but live
> with the fact that the filesystems are 90-97% full.
You can back up the filesystem, recreate the filesystem with newfs and a
lower blocks per inode factor and then restore the filesystem.
--
Jon Biggar
Floorboard Software
j...@floorboard.com
j...@biggar.org
David Cooke
>Mathew Kirsch wrote:
>> > I wonder how many people have this problem and have found solutions. I have
>> > a webserver with millions and millions of html files and gifs. What seems to
>> > happen is my disk will run out of space between 90% and 97%. I know it has
>> > something to do with blocks/inodes and when we make new partitons we are
>> > sometimes able to get around it by setting blocks per inode to a lower
>> > number.
>>
>> You've discovered both the cause of the problem, and the solution.
>>
>> Each filesystem is cut up into smaller chunks called inodes. These are 4
>> kilobytes in size by default, IIRC. So, the minimum size of any file would be
>> 4 kilobytes; even if the file is only 10 bytes long, it will take up 4
>> kilobytes of space on the disk.
>
>Good advice, but wrong in the detail. Inodes are not the same thing as
>block size. Each file or directory in the file system uses exactly one
>inode, which is of a fixed size. When the filesystem is created, a
>formula is used to determine the total number of inodes that are
>preallocated in the filesystem. Once you use them all, you cannot
>create any new files in that filesystem.
One minor correction: an inode contains a list of all the blocks that
make up a file. Since an inode is a fixed size, at some point more than
one inode is used to keep a list of all the blocks in a big file (or in
a sparse file).
I'm interested to know how you are measuring the free space on the
disk. Unpriviledged users (ie. not root) cannot normally fill a file
system beyond about 90%. This is in part because the performance of
the file system degrades rapidly beyond this point, and to leave root
some workspace to move things around after they've gone bad.
The "df -k" command reports based on the "unpriviledged" available
space, not the actual space remaining. This is for Solaris 8, other
Unix have different behaviour I think, some depending on who executes
df. I think when you create a file system you can specify the ratio
between unpriviledged-full and actually full state of the file system.
If your websites disks are nearly or over 90% full, then you may want
to consider the impact on performance of using the last 10% of the
disk. I guess that depends on the extent to which the performance
is disk IO bound.
David Cooke.
--
... has unselfishness ever marked an age?
Is not selfishness the identifying trait of the "human" race?
- Drew Struzan