[Linux-cluster] Abusing the GFS file system

[Wendy Cheng]

Wendy Cheng wrote:

> eric johnson wrote:
>
>> Suppose I'm on a GFS partition with 50 GBs free.
>>
>> And then I rudely drain it of inodes with a perl script that looks 
>> like this.
>>
>> Executive summary - make a bunch of randomly named files...
>>
>> --makefiles.pl
>>
>> my $i=0;
>> my $max=shift(@ARGV);
>> my $d=shift(@ARGV);
>> if (not defined $d) {
>>    $d="";
>> }
>> foreach(my $i=0;$i<$max;$i++) {
>>    my $filename=sprintf("%s-%d%s",rand()*100000,$i,$d);
>>    open FOO, ">$filename";
>>    print FOO "This is fun!!\n";
>>    close FOO;
>> }
>>
>>
>> In fact, to be extra cruel, I make a bunch of subdirectories on my
>> partition, and then run an instance of this script in each
>> subdirectory until the box is saturated with work to do and everyone
>> is busily draining away the inodes.  This takes a good 6 hours.
>>
>> Then when the inodes are drained, I kill the run away scripts and then
>> delete all the files that were created.
>>
>> While everything has been deleted, I still don't get back all of my
>> space.  In fact, the vast majority of it still appears to be chewed up
>> by GFS and it won't give back the space.  So when I copy large files
>> to it I get errors like...
>>
>> cp: writing `./src.tar.gz': No space left on device
>>
>> When that file is clearly under a gig and should fit.
>>
>> But if I run a gfs_reclaim on that partition, then it all magically
>> comes back and then I can place largish files back on the disk.
>>
>> Is this a well known characterstic of GFS that I somehow missed 
>> reading about?
>>
> hmmm ... look like a bug - the inode de-allocation code is supposed to 
> put the meta-data blocks back to free list. Thank you for let us 
> know.  Will open a bugzilla to fix this up.
>
Bug opened as: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218576

The difficult part of this issue is that we have to make sure no other 
node will hold this inode reference before assigning it to another new 
file.

-- Wendy