ADSM-L

Re: [ADSM-L] ANR8341I End-of-volume reached for REMOVABLEFILE volume

2010-02-06 17:25:41
Subject: Re: [ADSM-L] ANR8341I End-of-volume reached for REMOVABLEFILE volume
From: Steven Haigh <netwiz AT CRC.ID DOT AU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Sun, 7 Feb 2010 09:25:01 +1100
On Sat, 6 Feb 2010 13:33:57 -0500, Richard Sims <rbs AT BU DOT EDU> wrote:
> I think that part of the problem is that you have drive/volume
> expectations from Removeablefile devclass utilization, when in fact
> its a file-based mechanism.  Two things you could do are to assure
> that the devclass MAXCAPacity value is sized that that it has the
> potential for writing a file as large as the capacity of your device

It's interesting to note that I did not set the MAXCAPacity value in this
server. It seems TSM has decided on this value. It's interesting though as
the actual size that is on the disk is around 40Gb larger than the setting
for MAXCAP.

> (file system), and that your Unix resource limit "filesize" is not
> restricting the size.  Also beware file size limits for a chosen file
> system type, which can be influenced by the block size chosen when the
> file system was initialized.

I have looked at this. The filesystem is ext2 and created with 4Kb block
sizes. From what I have been reading, this would mean the max filesize
should be around 2Tb - more than plenty. I haven't been able to find any
other factors that could limit this. This is what the superblock contains
on this volume:

# tune2fs -l /dev/sdk1
tune2fs 1.39 (29-May-2006)
Filesystem volume name:   5QD7CKPM
Last mounted on:          <not available>
Filesystem UUID:          40c6f84f-6a3c-4a8c-9ac4-41b287cd320c
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      resize_inode dir_index filetype sparse_super
large_file
Default mount options:    (none)
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              39075840
Block count:              78142160
Reserved block count:     0
Free blocks:              39188058
Free inodes:              39075828
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1005
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16384
Inode blocks per group:   512
Filesystem created:       Thu Jan  7 12:51:44 2010
Last mount time:          Sat Feb  6 23:26:05 2010
Last write time:          Sat Feb  6 23:26:05 2010
Mount count:              19
Maximum mount count:      24
Last checked:             Thu Jan  7 12:51:44 2010
Check interval:           15552000 (6 months)
Next check after:         Tue Jul  6 11:51:44 2010
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Default directory hash:   tea
Directory Hash Seed:      6386ece4-aedd-46f2-af19-b437f371959d
Journal backup:           inode blocks

> As you have noted, there's scant info about Removablefile devclass.  I
> tried a search on the new Support page which alleges to replace the
> great TSM Support Page we once had - but the new Support page
> programming has severe defects, where it won't show more than 20
> search results, despite 190 hits.  (IBM's corporate self-delusion of
> replacing something that worked well for the customer base with
> something which satisfies corporate goals and nothing else.)

Maybe they don't expect people to use this type of device?

-- 
Steven Haigh
 
Email: netwiz AT crc.id DOT au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299