On Tue, 25 Nov 1997, Dave Hitz wrote:
All of the meta-data in WAFL is stored in hidden files with inode numbers in the range 32-63, except for the inode file itself, whose inode is stored at a fixed location on disk where it can be found at boot time. (Multiple fixed locations, actually.)
So when you use maxfiles to increase the number of inodes, both the inode file and the inode-map file need to be grown? I noticed that deleting a single 2GB file can take several seconds of 100% CPU usage on an F230. Is this simply because the filer has to work its way down 6 or 7 layers of inode indirect blocks (by my calculations) and gathering up the half million or so 4K blocks? Still, it's a little faster than an Ultra-1 running Solaris doing the same thing to a local filesystem. ;-)
That file is one MB per GB of disk space, so after the first snapshot in a brand new 100 GB filesystem, you should lose about 100 MB.
That sounds about right then... a total of 40MB was used after the first snapshot (including the stuff in /etc), and the filers have 9 4GB data drives.
Black-box reverse engineering at it's best. You remind me of some of the engineers here at NetApp. "Hey! Check out THIS new way to kill a filer..."
Or...
"Engineer, it hurts when I do *this*!" "Cool! Hold still and let me try it..."