HP3000-L Archives

August 1998, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jerry Fochtman <[log in to unmask]>
Reply To:
Jerry Fochtman <[log in to unmask]>
Date:
Tue, 18 Aug 1998 12:14:42 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (64 lines)
At 11:43 AM 8/14/98 -0800, Mark Klein wrote:
>Bruce writes:
>>Stan Sieler writes:
>
>>>   So...we said, hey...let's just do:
>>>           build foo; rec=128,1,f,binary; disc=1024,2,2
>>>   this builds a file of 1024 * 256 bytes, fully allocated on disk,
>>>   whose EOF is 0 and whose LIMIT is 1024.
>>>   Then, we HPFOPEN it (with long mapped access) and use it.
>
>>I have a number of scars to show for using this approach.
>
>ORBiT has as well. We discovered way back when (and to be sure, I'm not
>sure this is still the case), that when writing to pages beyond the EOF
>in a high memory pressure situation, the OS reused the real memory that
>those pages were mapped into without preserving the old pages. I think
>that Jerry Fochtman has seen something similar more recently (Jerry -
>wanna speak up?) that is simliar.

Yep....seems it's a known situation.  Dirty pages beyond the EOF and before
the end of the extent containing the EOF don't always get posted to disc
in high memory pressure situations when the file is closed without
pushing the EOF.  When using some specialized techniques in building a
file we've seen the initialization of this portion of the final extent
not get posted to disc.  Then when the file is subsequently re-opened and
the EOF pushed causing a new extent to be allocated, the file system
assummed that the remainder of the prevous last extent was
initialized and therefore only initialized the new extents being
allocated, not from the EOF position.  This left 'garbage' in the file,
which is generally not appreciated... ;-).

I would like to point out that this is not a situation users would
encounter, but rather a condition some tools using lower-level approaches
have encountered and as such, have had to worked around.


>Now I know this isn't exactly what Stan's doing as he's counting on
>this not being durable, whereas ORBiT was doing the opposite. I just
>want to point out that this technique is ripe with "gotchas".

I agree.  May work fine on a lot of systems but there will be a point
when doing something like this on a high memory pressure system where
the timing of events will cause the dirty pages above the EOF not to be
posted....and always at the most inopportune time!



/jf
                              _\\///_
                             (' o-o ')
___________________________ooOo_( )_OOoo____________________________________

                          Tuesday, August 18th

          Today in 1587 - Virginia Dare became the 1st English child to
                          be born in America.


___________________________________Oooo_____________________________________
                            oooO  (    )
                           (    )  )  /
                            \  (   (_/
                             \_)

ATOM RSS1 RSS2