Re: Unix Command

On 04/20/2006 10:44:12 PM, Steve Perry wrote:
> Somebody else mentioned the same thing with 9i, AIX on EMC Symmetrix.
> She dropped a tablespace and datafiles. It took 12 hours or more
> before they could reuse it.
>
> i'd love to know if this is an oracle issue or OS.
> Right now it's just finger pointing.
>

It's always an OS issue. There is a little beast called inode and that beast points to the map of so called data blocks. The number of inodes is fixed and determined at file system creation time. When you delete a file, there are several things that have to happen:
1) All data blocks pointed to by the inode (file=inode) have to be declared free

   and added to the map of free data blocks (typically a bitmap, pointed to by a    superblock).
2) Bitmap of free blocks (this is a real bitmap: 1 if the block is free, 0 if in use, 1

   bit per FS block) has to be updated appropriately.

3) FS statistics in the superblock(s) must be updated.
4) inode has to be cleaned and declared free (another bitmap in the superblock).
5) All that information must be flushed from the core and written to the disks, in various

   forms (journalling FS protects transactions on inodes, which means that "file headers" or    inodes will be consistent, even if your system crashes in the middle of the event and that    you will not have the privilege to run fsck and possibly, just possibly, lose files) 6) File name has to be removed from the directory.

The problem here is that if any process has the inode marked as "in use", the OS will only remove the file name from the directory, but will not perform any of the inode/superblock operations. Your "free space" comes from the FS statistics within superblock. So, your OS thinks that the inode is in use. If fuser or lsof disagree, then your OS is plain wrong. There used to be a trick to do it on XFS on SGI Irix 5.2, the trick was to run fsck -r on the underlying device while the OS was mounted. This was possible, of course, only as a root user. This was unsupported trick that made SGI support scream. This command, fsck -r, runs interactively and asks you to fix any problems that it finds. It will find many while the system is running. DO NOT FIX any of those unless it is about free blocks not being properly marked. You can ruin and corrupt your FS if you don't know what you're doing. I suspect that IBM support will also scream if you mention to them what I just described you.
Another way of doing that is marking the inode as free with kernel debugger and then running "sync" few times. These are all operations ideally suited for a beginner, good for practicing after reading "Teach Yourself Unix in 24 hours".

-- 
Mladen Gogala
http://www.mgogala.com

--
http://www.freelists.org/webpage/oracle-l