[popesy]

Hi all

I have a SAN presented LUN on an LPAR (mirrored at the storage side) and am wondering does anyone know if I am ok to run the fsck against a possible corrupt file system residing on the LUN.

Cheers

JP

[ross.mather]

Yes you can. fsck will detect errors in how the data is stored on the disk. The fact that it is on the SAN makes no difference to the functioning of fsck.

[popesy]

Ross

Cheers for that, I had thought so and have ran the fsck utility against a file system that has been misbehaving...

The story went like this;

Our DBAs reported that some of the oracle file system were visible in the with 'ls' but when you added flags i.e. 'ls -ltr' the files/directories are not shown

Umounted the /u01 ran fsck against the /u01 and this showed some invalid in inode references and superblock. I ran 'fsck -y /u01' and this cleaned up the fs but removed the invalid references.

Is there a neat way of retrieving the missing files/directories from the 'lost+found' directory? There are loads if inodes in there...

Cheers

JP

[popesy]

Update to our u01 fs corruption;

It turns out that 2 different LPARs (both showing the 'corruption') seem to be sharing the same SAN allocated disk. So actions I was taking on one was affecting the other and vice versa - not really a corruption, rather human interference/error :-)

So, I checked the pvid in the ODM on both LPARs and they report the same pvid, this is suggesting to me that the same disk is being used by both LPARs. My assumption is that at some point when these disks were allocated by the VIOS to the corresponding LPAR vhost that this was done erroneously and maybe not entirely corrected.

My actions now are to trace what has happened in terms of allocating these SAN disks and see whether my assumption is correct.

Any advice as to other thoughts around this are welcome. Will update as soon as I have something to add.

Cheers

J