Path: utzoo!attcan!uunet!husc6!cca!mirror!rayssd!galaxia!amanpt1!mrr
From: mrr@amanpt1.zone1.com (Mark Rinfret)
Newsgroups: comp.sys.amiga
Subject: Re: a plea for bad block handling in the filesystem
Summary: While we're talking about it...
Message-ID: <464@amanpt1.zone1.com>
Date: 21 May 88 21:16:09 GMT
References: <1025@astroatc.UUCP>
Organization: Aquidneck Management Associates
Lines: 94

In article <1025@astroatc.UUCP>, jojo@astroatc.UUCP (Jon Wesener) writes:
> 
> 	Since the current trend is to put the bad block handling
> in the drivers, ... goes on to talk about bad block handling...
> ...
>                                         This all depends on how easy
> it is to allocate specific disk blocks.

Since you brought it up, I'd like to grab the opening.  How about some
lower-level disk support along the lines of:

/* The following flags determine the "flexibility" level of the request.
 * Of course, the letters BARF are an abbreviation for "Block Allocation
 * Request Flag", not an allusion to some of the feedback I'm expecting. :-)
 */

#define BARF_RIGID              0x00 /* No substitutions. */
#define BARF_PARTIAL_ALLOCATION 0x02 /* Allow less than requested. */
#define BARF_SUBSTITUTE_BLOCK 	0x04 /* Allow alternate starting block. */

typedef struct {
    /* This field specifies where we'd like to start the allocation.  If
     * it's zero, we don't give a hoot.
     */
    LONG bar_StartingBlock;
    LONG bar_desiredCount;           /* How many blocks we'd like to get. */

    
    LONG bar_ActualBlock;            /* The system sets bar_ActualBlock to 
                                        the first block allocated. */
    LONG bar_ActualCount;            /* How many blocks we actually got. */
    WORD bar_Flags;                  /* Request flexibility flags. */
    WORD bar_Result;                 /* Completion code.  This can be a
                                        combination of the flags above or
                                        other status codes indicating the
                                        type of failure (bad flags, no blocks,
                                        etc. */
    } BlockAllocationRequest;

WORD AllocateBlocks(request);
            BlockAllocationRequest *request;

	where
            return result == status (copy of bar_Result)
            request is a pointer to a BlockAllocationRequest, filled in
            by the user prior to the call, and containing useful info
            after the call.

Of course, the above is all probably implemented in 1.3 or the new FFS or
something else I don't know about.  Also, please don't take my model above
too literally.  I'm sure it could all be done with some permutation of the
standard I/O request.  Support as I've outlined above would allow the
creation of smart file copy programs, possibly even background hard disk
optimizers (Holy defragmentation, BatMan!).

Since I'm started, how about another one:

BOOLEAN	SetFileInfo(lock, info);
		struct FileLock *lock; struct FileInfoBlock *info;

This routine would do a smart copy of certain file parameters defined by
<info> to the file defined by <lock>.  For starters, the info to be copied 
would include:

	File Name (useful if copying a file to a file of the same name on
                   a different device or directory)
        File Comment (I like these - let's use 'em!)
        File creation/modification date
        File permission flags
        
While the individual pieces of support are already in AmigaDos, it sure
would be nice to see them bundled up into one coherent call.  Heck, programmers
might even be encouraged to do things right if it's easy enough!  Programs 
like vi might remember that my filename was capitalized.  The multitude of 
copy programs might even maintain vital statistics (no holy war discussions 
on copied file dates, please).  Thanks for your time...
> 
> --j
> -- 
> jon wesener

	Nice idea, jon.

Mark
> ... {seismo | harvard | ihnp4} ! {uwvax | cs.wisc.edu} ! astroatc!jojo
> 
> "do us all a favor, get yourself a spine."  -- replacements


-- 
< Mark R. Rinfret,  mrr@amanpt1.ZONE1.COM | ...rayssd!galaxia!amanpt1!mrr    >
< AMA / HyperView Systems               Home: 401-846-7639                   >
< 28 Jacome Way                         Work: 401-849-9930 x301              >
< Middletown, RI 02840          	"If I just had a little more time...">