[Linux-cluster] Abusing the GFS file system

[eric johnson]

thanks wendy!  i'll lurk in the background then.

On 12/6/06, Wendy Cheng <wcheng at redhat.com> wrote:
> 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
>
>
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster
>