- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Output of "show dev d" seems not correct
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-06-2010 05:45 AM
тАО07-06-2010 05:45 AM
Re: Output of "show dev d" seems not correct
If the disk is active and with application I/O channels open here, then it's entirely possible to have temporary files active within the file system but that are not visible to DIRECTORY. Caches and scratch files and such.
Active OpenVMS system disks are expected to have various active files and cache activity and locked files.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-06-2010 07:44 AM
тАО07-06-2010 07:44 AM
Re: Output of "show dev d" seems not correct
I suspect you already know which files have trouble, and possibly why.
But if you need some further clarification, then get DFU installed from http://www.digiater.nl/dfu
(Hint : $ DEFINE DFU$NOSMG YES )
With that in place you ask for the big files:
$ DFU SEARC/SIZE=MINI=1000000 $1$DGA100
You will find this will finish in seconds, not minutes compared to the $ DIR/SIZE=ALL/SELE=SIZE=UNUSED=nnnn
An interesting alternative:
$ DFU SEARCH / OVER_ALLOCATED = n
I also like /FRAG=MINI=nnn
And of course the simple REPORT $1$DGA100
The directory tree deletion is nice also, although I find it too verbose, and I find it odd not being able to specify a directory ( [xxx.yyy] ), but only a directory file ( [xxx]yyy.dir )
$ DFU DELE /DIRE/TREE/NOLOG xxx.DIR
fwiw,
Hein
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-06-2010 11:54 AM
тАО07-06-2010 11:54 AM
Re: Output of "show dev d" seems not correct
That's another reason for using DFU, it can see lost files, since it looks directly in the INDEXF.SYS file (where the file headers live), instead of traversing the directories.
See attachment for an example of creating an over allocated file, "losing it", and showing that directory won't find it, but DFU will.
I agree with Hein, DFU is well worth installing. It is much faster than directory, especially on a device that has 3025 directories and 91108 files.
Note, that if you want to use DFU to find files that are consuming space, you need to use the /allocated switch.
Here's an example of the difference. (trimmed, see attachment for complete output)
$ dfu search /size=min:400000/sort sys$sysdevice
DSA1407:[TCPIP$FTP]TCPIP$FTP_RUN.LOG;697 433780/433792
%DFU-S-FND , Files found : 1, Size : 433780/433792
$ dfu search /size=min:400000/allo/sort sys$sysdevice
DSA1407:[TCPIP$FTP]TCPIP$FTP_RUN.LOG;697 433780/433792
DSA1407:[VMS$COMMON.SYSEXE]SYS$QUEUE_MANAGER.QMAN$JOURNAL;1 2/421792
%DFU-S-FND , Files found : 2, Size : 433782/855584
$
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-06-2010 12:56 PM
тАО07-06-2010 12:56 PM
Re: Output of "show dev d" seems not correct
Truncation will help if the the difference between used and allocated is .ge. one cluster. However, you can only truncate a file with set file/trucate if the file is not opened by any process (in the cluster). Otherwise you will get a file access conflict error.
This true even if the file is opened for write sharing.
$ copy sys$login:login.com disk$uio:[000000]/allo=100000
$ dir /siz=all disk$uio:[000000]login.com
Directory DISK$UIO:[000000]
LOGIN.COM;245 22/100000
Total of 1 file, 22/100000 blocks.
$ open/app/share=write foo disk$uio:[000000]login.com
From another process..
$ set file/trun disk$uio:[000000]login.com
%SET-E-READERR, error reading DISK$UIO:[000000]LOGIN.COM;245
-SYSTEM-W-ACCONFLICT, file access conflict
Also, analyze disk/repair does not truncate files.
$ close foo ! back to original process that had file open
$ anal/disk/rep disk$uio
Analyze/Disk_Structure/Repair for _DSA3406: started on 6-JUL-2010 16:50:08.87
%ANALDISK-I-SHORTBITMAP, storage bitmap on RVN 1 does not cover the entire device
%ANALDISK-I-OPENQUOTA, error opening QUOTA.SYS
-SYSTEM-W-NOSUCHFILE, no such file
$ dir /siz=all disk$uio:[000000]login.com
Directory DISK$UIO:[000000]
LOGIN.COM;245 22/100000
Total of 1 file, 22/100000 blocks.
$ set file/trun disk$uio:[000000]login.com
$ dir /siz=all disk$uio:[000000]login.com
Directory DISK$UIO:[000000]
LOGIN.COM;245 22/24
Total of 1 file, 22/24 blocks.
$ del disk$uio:[000000]login.com;
$
Jon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-06-2010 03:08 PM
тАО07-06-2010 03:08 PM
Re: Output of "show dev d" seems not correct
XXXX:SYSTEM> dir /size=(alloc,unit=byte)/total
Directory SMSC$ROOT:[LOG]
Total of 58 files, 59.40GB
I am not sure what's the cause.
Can help to suggest me the safest step to try troubleshooting ?
-----------------------------------------
These files are open by some application, and you will need to determine what that is. The easiest way is to use the command:
$ show device/files SMSC$ROOT /out=sys$scratch:smsc.files
$ search sys$scratch:smsc.files ".LOG]"
You will need to do this from every member of the VMS cluster, since each node will only display files that are opened on the current node.
This will display the process name and process id (8 hex digits) that has the file open. If the process name does not help, you can use analyze/system to see more about the process.
Suppose this was the output:
SMSC1 20800411 [SMSC.LOG]ABCD.LOG;32
$ analyze/system
SDA> set process/ind=20800411
SDA> show process/chan ! this will display all the files open by the process and will give a good clue
SDA> exit
Now you need to determine how to get that process to close the file. Then you can copy it somewhere else, and restart the process with an new log file.
Jon
a Google search for smsc$root found this
http://www.scribd.com/SMSC-52MR4-Installation-Manual/d/20342007
which appears to be software from Acision that uses RdB. SMSC is an abbreviation for Short Message Service Centre
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-07-2010 02:20 AM
тАО07-07-2010 02:20 AM
Re: Output of "show dev d" seems not correct
Thanks for the tips to check open files.
Yes, this system is SMSC.
The disk is normal now.
I stop all processes that still lock files, then delete those files.
The disk occupancy back to normal.
I want to ask regarding the locked files :
dir /size=all
XXX00.DUMP;1 0/*******
XXX01.DUMP;1 0/*******
XXX02.DUMP;1 0/*******
It shows 0 of used, but so big in allocated.
Can help to explain how OpenVMS decides block size for used and allocated for 1 process?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-07-2010 02:58 AM
тАО07-07-2010 02:58 AM
Re: Output of "show dev d" seems not correct
So if an application just opens a file once, and only closes when the program terminates, then it shows 0 blocks used, and a growing number of blocks allocated.
Some utilities do close/reopen log files on a regular interval, so one can see the used block s in a directory listing.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-07-2010 11:10 AM
тАО07-07-2010 11:10 AM
Re: Output of "show dev d" seems not correct
I want to ask regarding the locked files :
dir /size=all
XXX00.DUMP;1 0/*******
It shows 0 of used, but so big in allocated.
Can help to explain how OpenVMS decides block size for used and allocated for 1 process?
-----------------
Joseph Huber explained why the used size is displayed as zero. Unless a process explicitly request that the EOF (End Of File) pointer is updated, it will remain static. It gets updated when the file metadata gets resynched by the programs request; either an RMS $FLUSH or when the file is closed. If the file is created when it is opened, then written to for a long period of time, then the file will continue to be extend the file's allocated space to make room for the data. The end of data pointer is constantly updated in the memory of the process writing the data, but unless the metadata is resynched, the updated value will not be visible to other processes, and what is displayed by directory/size=used will remain 0.
In the directory output above, the files were larger than 5 GB (9,999,999). The default width for the size field is 7, so the allocated blocks were displayed as ********. To see the actual value, you can user directory/full file or directory/width=(size=12)/size=all (see help dir/width)
The used/allocated concept isn't unique to VMS, windows does the same thing, although is a bit harder to see the "allocated" space in windows. The allocated space in windows shows up in file properties as "Size on Disk".
Size: 706 bytes (706 bytes)
Size on Disk: 4.00 KB (4,096 bytes)
------------------
There is probably a cleaner way to get the processes to close and open a new .dump file than to stop the process, but I know nothing about the SMSC software. You will need to consult the documentation for that.
Jon
- « Previous
- Next »