Conference decwet::advfs_support

1067.0. "write error 5 and bind set volume" by TKTVFS::SUWABE (Susumu Suwabe /OCC/CSC/MCS) Tue May 27 1997 02:17

I'd like to ask about ADVFS. 

Customer system configuration(SONY);

        Alpha Server 8200
        KZPSA
        SW500
        HSZ40 V3.0

	digital unix V4.0

    Bind volume set(2 raid 5 volume set)
        RZ29B x 5 raid 5,       RZ29B x 5 raid 5     
        BMT=683                 BMT=665

        *BMT=Bit Map Metadata, 683 is the maximum extension limit of BMT.

Customer concern;

        If the write command invoked to the bind volume set, 
the "write error 5"(EIO) had been returned. It was caused of insufficient BMT 
resouces. We have alreadey changed it's BMT size to adequate size and then
problem has gone. The customer(SONY) accepted this action. But they have had 
some concern about ADVFS execution.
 
        This strage system is a bind volume set. If the one volume reached it's
BMT extend limit, 683, the IO write command should be changed it's target 
volume to the another one that has free BMT area. User should not receive 
"write error 5"(EIO) when she/he has another free BMT space.
        We could produce same error in our test site, BMT was default size, 
creat much files.


Customer would like to know;

        1) Whenever the BMT reached its limit, 683, the kernel shread could not 
           change its target volume to free BMT disk in bind volume set 
	   enviroment.
           Is that true?

        2) If yes, I think ADVFS in todays version has had implementation or 
	   some architecture problem. Right?

           Or, todays ADVFS has implemented it's architecture. This error is
           caused of a manner of architecture. Right?

	3) If anyboby has some guide/manual/web site information about ADVFS 
	   architecture and bindset volume system operation flow, 
	   could you please reply that site?

Regards,

S.Suwabe
Japan MCS/CSC/PSI

 

    The AdvFS team is aware of the BMT extent problem and is planning work
    in a future release to avoid getting into BMT extent problems.
    
    In the mean time, the mkfdmn and addvol commands have the -p and the -x
    options to allow larger "Pre-allocation" and larger "eXtents" when
    creating a domain or adding a volume to the domain (Digital UNIX v4.0
    and greater).
    
    If spare disk space is available, additional volumes can be added to
    the domain, and a volume with a highly fragmented BMT can be removed. 
    Then the removed volume can be added back in with larger -p and -x
    values.  Repeat for each volume with a highly fragmented BMT in the
    domain.  Finally the spare disk space can be removed, but now you have
    much cleaner BMTs on the original volumes in the domain.  The spare
    disk space can be any collection of disks and/or partitions as long as
    the resulting storage is sufficient to allow removing one of the
    existing volumes at a time.
    
    					Bob Harris

And to answer your last question, yes AdvFS has an architecture problem.  We
have been working on this problem since OSF/1 v2.0 (if not earlier), and are
getting closer to a solution, but we aren't there yet.

The HSZ40, bind configuration RAID sets have nothing to do with this problem.

--Ken

Harris-san and Martin-san 

	Thank you for your honesty answer.
I decided to close this problem as a management issue, not a technical.
Advfs engineering team do the good job. 

Susumu Suwabe
Japan MCS/CSC/SDO