So I have a guest whose /usr I want to freeze and stick into a DCSS.
I can easily do this if the DCSS is SW or EW.
But I really want an SR DCSS, since I want everyone to share the
filesystem but I don't want anyone (except the owner) to write to it
ever, and the owner only to do so very infrequen
Ref: ftp://ftp.bmc.com/pub/linux/dcss-cms.html
Richard,
In your write up, you perform these steps:
> defseg segusr 1-3 sr
> pipe < segusr ext2 | storage 1000 805306368 e0
> saveseg segusr
What you need to avoid problems from CMS is:
CP DEFSEG SEGUSR 1-3 SR
SEGMENT RESERVE SE
On Monday, 02/16/2004 at 02:09 CST, Adam Thornton
<[EMAIL PROTECTED]> wrote:
> So I have a guest whose /usr I want to freeze and stick into a DCSS.
>
> I can easily do this if the DCSS is SW or EW.
>
> But I really want an SR DCSS, since I want everyone to share the
> filesystem but I don't want an
On Mon, 2004-02-16 at 14:52, Alan Altmark wrote:
> Did you try the sequence I gave last week? The trick, I believe, is to
> load the SR segment in exclusive write mode, which gives you a private
> non-shared r/w copy of a r/o DCSS. When you do that, mount it, fill it,
> and save it, no one can ch
Again, Alan, why exclusive write mode? Do you mean EW? Or that this
sequence be followed:
(userid with class E has storage greater than the end of the desired
segment).
(userid with class E): DEFSEG LINFILES. SR
(userid with class E): load up the segment through whatever means ...
(userid
A segment defined as EW is EW for all its users.
David Kreuter
Adam Thornton wrote:
On Mon, 2004-02-16 at 14:52, Alan Altmark wrote:
Did you try the sequence I gave last week? The trick, I believe, is to
load the SR segment in exclusive write mode, which gives you a private
non-shared r/w copy
This is wandering off into the weeds a bit:
How hard would it be to teach Linux about XC mode?
I mean, a most-console-stuff shared filesystem, before any big apps go
on it, is close to 500M. I can see wanting well over a gig there. The
problem, of course, is that (virtual machine size) + (files
On Mon, 2004-02-16 at 15:12, David Kreuter wrote:
> A segment defined as EW is EW for all its users.
Ah. But the "exclusive-writeable" flag in the Linux DCSS driver is
orthogonal to the segment definition. Right? Or is it?
I'm confused.
Adam
pretty big deal as the linux implementations I have worked with all turn
on the DAT bit.
Linux is pretty sophisticated about address space handling as compared
to say CMS.
XC - extended configuration - mode was more or less invented as a way
for a DAT off
o/s (CMS) to get at dataspaces. Data space
XC doesn't/can't/won't work in DAT mode. You take away DAT from Linux and
you don't have virtual memory that the machine can manage.
-Original Message-
This is wandering off into the weeds a bit:
How hard would it be to teach Linux about XC mode?
I mean, a most-console-stuff shared files
On Monday, 02/16/2004 at 03:05 CST, Adam Thornton
<[EMAIL PROTECTED]> wrote:
> Does my exclusive-write copy become the "real" copy when everyone who
> had links to it has logged off? I guess that's what's confusing me:
> when I do the updates to it, and I'm really changing my private copy, do
> t
On Mon, 16 Feb 2004, Alan Altmark wrote:
> Your exclusive-write copy does not become the "real" copy until you save
> it (per the book) by writing to /save, wherein Linux will issue the DEFSEG
> and SAVESEG for you when you subsequently close the DCSS file.
By writing *what* to /save? Random byte
On Mon, 2004-02-16 at 15:59, Alan Altmark wrote:
> The linux term "exclusive write" is the same as the VM term "non-shared
> copy". It is NOT the same as a DCSS defined with Exclusive Write (EW)
> attributes, and it does not prevent access to the existing copy of the
> DCSS.
OK, I think this is p
On Monday, 02/16/2004 at 04:29 CST, Adam Thornton
<[EMAIL PROTECTED]> wrote:
> On Mon, 2004-02-16 at 15:59, Alan Altmark wrote:
> > The linux term "exclusive write" is the same as the VM term
"non-shared
> > copy". It is NOT the same as a DCSS defined with Exclusive Write (EW)
> > attributes, and
I see greater use of FS labels coming from this.
The driver will need to work with /proc/partitions
because that is where 'mount' reads filesystem labels.
-- R;
>I see greater use of FS labels coming from this.
>The driver will need to work with /proc/partitions
>because that is where 'mount' reads filesystem labels.
Why would you want to use FS labels? Just make your DCSS have talkative
names!
with kind regards
Carsten Otte
--
I saw screens of green,
Argh. I wish I would have been more stubborn and unfriendly towards the
developer when I explained to him that both the way of working and the
documentation were unlike what we use to do on VM and thus would confuse
people and make them do things they don't want to do. Let me start from
the beginni
Carsten Otte wrote:
Why would you want to use FS labels? Just make your DCSS have talkative
names!
I believe I would also be reluctant to have everyone look into the
segments to see whether they like it. But there would be room for some
additional mapping layer (so that you can do some manage
On Tuesday, 02/17/2004 at 12:03 CET, Rob van der Heij <[EMAIL PROTECTED]>
wrote:
> 2. The alternative approach is hat you first save a dummy DCSS. So take
> a MAINT user with large enough virtual machine size and issue the DEFSEG
> and SAVESEG just to save the DCSS with garbage). The Linux guest
>
Alan Altmark wrote:
SAVESEG also requires class E. The /save function of the driver was
designed assuming the Linux machine has class E privileges (from my
reading of the code), as it automatically issues the DEFSEG and SAVESEG
for you. If you don't want to give the Linux image class E, then the
Rob
van der Heij
Sent: Tuesday, February 17, 2004 6:04 AM
To: [EMAIL PROTECTED]
Subject: Re: DCSS permission question
Argh. I wish I would have been more stubborn and unfriendly towards the
developer when I explained to him that both the way of working and the
documentation were unlike what we use
On Tue, 17 Feb 2004, Post, Mark K wrote:
> This write-up, along with the subsequent exchange between you and Alan,
> would make a really nice addition to the HOWTOs page. Would you be willing
> to write this up in HTML format for that?
And I note that although Rob mentions two different methods,
Alan Altmark wrote:
Be aware that loading the segment in exclusive-write mode will purge the
existing segment, preventing any *subsequent* loading of the segment, read
OR write. Existing users of the segment are unaffected.
He probably went out for lunch and Chucky grabbed the keyboard. I
believ
Richard Troth wrote:
And I note that although Rob mentions two different methods,
neither of those matches what I did here. As Adam pointed out,
it will appear a bit convoluted. But it seems to work well.
Neat, Sir Santa. That certainly does the trick as well. You could even
make the pipe twe
On Tuesday, 02/17/2004 at 06:19 CET, Rob van der Heij <[EMAIL PROTECTED]>
wrote:
> Alan Altmark wrote:
>
> >Be aware that loading the segment in exclusive-write mode will purge
the
> >existing segment, preventing any *subsequent* loading of the segment,
read
> >OR write. Existing users of the segm
A little weirdness with the DCSSBLK driver:
dcss2:~# mount /dev/dcssblk/USR /usr
mount /dev/dcssblk/USR /usr
dcss2:~# df
df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/dasd/0150/part1174248104572 60684 64% /
/dev/dasd/0151/part1396744360588 1567
I think it's a VFS or other Linux bug.
I've seen this with other block drivers when overmounting. Dunno why.
-- R;
On Tue, 2004-02-17 at 11:48, Alan Altmark wrote:
> It's the cough syrup.
So *that*'s where it went.
Adam
> It's the cough syrup.
That's Cough Syrup (tm). When straight Scotch just doesn't cut it, use Cough
Syrup.
Recommended by quality consultants everywhere...8-)
-- db
PS -- Does not include Linux kernel hacking ability. Keep away from pets and
small children. Do not use externally. Mileage may
David Boyes
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
ine.net> cc:
Sent by: Linux Subject: Re: DCSS permission question
on 390 Port
<[E
[EMAIL PROTECTED]>
Sent by: Linux on 390 Port <[EMAIL PROTECTED]>
17/02/2004 07:05 PM
Please respond to Linux on 390 Port
To: [EMAIL PROTECTED]
cc:
Subject:Re: DCSS permission question
A little weirdness with the DCSSBLK driver:
dcss2:~# mount /dev/dcssblk/
Bruce's suggestion probably helps,
but as I wrote it up there is still another problem.
On Tue, 17 Feb 2004, Bruce Hayden wrote:
> What you need to avoid problems from CMS is:
>
> CP DEFSEG SEGUSR 1-3 SR
> SEGMENT RESERVE SEGUSR (USER SKELETON
> SETKEY 14 SEGUSER (FINDSKEL
> PIPE < SEGUSR
> That sounds like Lydia Pinckum's (renamed as Lilly the Pink by the Beetles)
The Scaffold.
--
Phil Payne
http://www.isham-research.com
+44 7785 302 803
33 matches
Mail list logo
