headers
Eric Rothweiler | 1 May 2008 13:48
Picon

Re: Disk space. Linux NCP volumes

Look at it this way - on NetWare multiple volumes can be placed inside the
same NSS pool.  When you do a properties of either volume you will see the
info on spaced used by that volume but total space free for both (as a
default).  Same thing here, the mount point is analgous to a pool and the
NCP volumes are, well, volumes.  The difference is that Reiser and EXT3 were
not designed with anything special for thee type of uses so there is no way
to do further configuration to prevent this behaviour.
Even if it is annoying it's not wrong, it's showing you the truth of what is
available in free space.

Eric

On 4/28/08, joea <at> j4computers.com <joea <at> j4computers.com> wrote:
>
> IMHO, it's "wrong" to see the same space, since they are "supposed to be"
> different volumes.
>
> I typo'd in my orignal post, while they are under the same mount point,
> they are different branches in the directory structure.
>
> joe a.
>
> >>> "Eric Rothweiler" <jetadmin <at> gmail.com> 04/28/08 2:05 PM >>>
> If the Linux mount point that houses both NCP volumes is one and the same
> then yes, you are seeing what you should.  Try using 'df -h' instead.  i
> also highly reccomend creating a new mount point for any NetWare volumes.
> In practice I will make /usr/novell/VOL1 and /usr/novell/VOL2
> etc.  Lessens
> room for confusion and you still have LVM underneath to adjust space as
> needed (NSS volumes are another story)
(Continue reading)

Permalink | Reply | 0 comments |
headers
joea@j4computers.com | 1 May 2008 17:40
Favicon

RE: Re: Disk space. Linux NCP volumes


I do not have access to the system, at this time, but reading my original post, 
wherein I presume I wrote correctly, it is not the space available, but the
space in use that was the issue.

joe a.

------- Original Message -------
>From    : Eric Rothweiler[mailto:jetadmin <at> gmail.com]
Sent    : 5/1/2008 7:48:09 AM
To      : novell <at> netlab1.oucs.ox.ac.uk
Cc      : 
Subject : RE: Re: Disk space. Linux NCP volumes

 Look at it this way - on NetWare multiple volumes can be placed inside the
same NSS pool.  When you do a properties of either volume you will see the
info on spaced used by that volume but total space free for both (as a
default).  Same thing here, the mount point is analgous to a pool and the
NCP volumes are, well, volumes.  The difference is that Reiser and EXT3 were
not designed with anything special for thee type of uses so there is no way
to do further configuration to prevent this behaviour.
Even if it is annoying it's not wrong, it's showing you the truth of what is
available in free space.

Eric

On 4/28/08, joea <at> j4computers.com <joea <at> j4computers.com> wrote:
>
> IMHO, it's "wrong" to see the same space, since they are "supposed to be"
> different volumes.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Peter Van Lone | 3 May 2008 15:37
Picon

2 SANs, 2 LUNS, mirrored! YA!

So, thanks largely to the assistance and reassurance of folks on these
lists, I have now successfully migrated data from an old SAN to a new
one. The mirror process has worked great -- spectacular, actually
(thus far, 2 partitions left to go).

A big round of applause to you all ....

Next question (you KNEW it was coming!): Is there a better or worse
way to break the mirror?

Would it be better to disconnect the fiber to the "old" SAN and thus
effectively physically break the mirror?

Or, would it be best to brave the possibility of deleting the wrong
segment from the raid device in NSSMU?

If I do go the NSSMU route, I just want to check my logic: I assume
that since I need to keep the "raid device" in tact, I simply go to
the properties of the raid device (hit enter on it) and then highlight
and "del" the segment that is on the old SAN to remove it from the
raid device. Then, for sure, I would want to disconnect fiber, just to
cleanly get rid of it.

So far this process has been seamless to the cluster, that just rocks.
And, it blows me away a little -- very very nice. I'm still a bit
mentally frizzed that simply mirroring the partitions also manages to
establish/create the pools -- but I guess that is the magic juju of
clustering, eh?

Peter
(Continue reading)

Permalink | Reply | 6 comments |
headers
Brian Chan | 3 May 2008 15:39
Favicon

Chan, Brian is out of the office.


I will be out of the office starting Mon 04/28/2008 and will not return
until Mon 05/05/2008.

I will respond to your message when I return.
Permalink | Reply | 0 comments |
headers
joea@j4computers.com | 4 May 2008 15:50
Favicon

BE hangs on Server Specific Info, Netware

A Backup Exec job, that has run "for a long time" has recently, and consistently, hung on backing up Server
Specific Info.  While it seems to almost complete that segment, it never logs the totals for that job. 

When this happens "no on can log in" and "a power off is required" to get things going again.  I have only
assured myself that logins to not happen when in that condition, coming in remotely.

This is BE 9.2, NW 6.5 (sp5) Dell 2600, RAID 5. 2GB RAM. LTO tape drive.

I have created other jobs, as a test, that do not include SSI and they run without issue.

Ideas? (possible h/w, I know, but will have to convice Dell, very likely)
Permalink | Reply | 1 comment |
headers
Gazunis, Chris | 4 May 2008 16:15

RE: BE hangs on Server Specific Info, Netware

Joe, 
I ran across this thread a while ago when I was having a problem with
server spec info.
http://groups.google.com/group/novell.support.netware.6x.abends-hangs/br
owse_thread/thread/8f0763521e1345d3

Basically it's a short thread w/ the resolution backreving to
TSA5UP18.EXE.

Chris

-----Original Message-----
From: novell-bounces <at> netlab1.oucs.ox.ac.uk
[mailto:novell-bounces <at> netlab1.oucs.ox.ac.uk] On Behalf Of
joea <at> j4computers.com
Sent: Sunday, May 04, 2008 9:50 AM
To: novell <at> netlab1.oucs.ox.ac.uk
Subject: BE hangs on Server Specific Info, Netware

A Backup Exec job, that has run "for a long time" has recently, and
consistently, hung on backing up Server Specific Info.  While it seems
to almost complete that segment, it never logs the totals for that job. 

When this happens "no on can log in" and "a power off is required" to
get things going again.  I have only assured myself that logins to not
happen when in that condition, coming in remotely.

This is BE 9.2, NW 6.5 (sp5) Dell 2600, RAID 5. 2GB RAM. LTO tape drive.

I have created other jobs, as a test, that do not include SSI and they
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alister Leask | 4 May 2008 23:13
Picon

Re: 2 SANs, 2 LUNS, mirrored! YA!

When I've done this in the past I have always removed the storage
before I deleted the old partition from the mirror group - that way I
was always sure that I was deleting the correct partition.

Pete, maybe I missed it previously but I'm not sure that you mentioned
clusters. You need to either mirror the SBD partition (can't be done
from NSSMU, IIRC) or shutdown the cluster and recreate the SBD on the
new storage. I've used the technique when recreating the cluster
partition of only presenting the LUN that will hold the SBD to the
server where you are recreating the SBD, so that there is no confusion
about where the SBD ends up.

On Sun, May 4, 2008 at 1:37 AM, Peter Van Lone <petervl <at> gmail.com> wrote:
> So, thanks largely to the assistance and reassurance of folks on these
>  lists, I have now successfully migrated data from an old SAN to a new
>  one. The mirror process has worked great -- spectacular, actually
>  (thus far, 2 partitions left to go).
>
>  A big round of applause to you all ....
>
>  Next question (you KNEW it was coming!): Is there a better or worse
>  way to break the mirror?
>
>  Would it be better to disconnect the fiber to the "old" SAN and thus
>  effectively physically break the mirror?
>
>  Or, would it be best to brave the possibility of deleting the wrong
>  segment from the raid device in NSSMU?
>
>  If I do go the NSSMU route, I just want to check my logic: I assume
(Continue reading)

Permalink | Reply | 5 comments |
headers
Peter Van Lone | 5 May 2008 02:00
Picon

Re: 2 SANs, 2 LUNS, mirrored! YA!

Allister ...

I went ahead and braved it -- the interface is actually pretty clear
in NSSMU and the only way I could see messing it up (now that I've
done it 8 times) is to slip and move the selection accidentally, or
just not paying attention.

As for the cluster -- yes, it was clustered and my SBD was one
partition amongst 3 on one LUN -- I just mirrored/broke the mirror
like every other partition. The only consequence was that one of the
three cluster servers (the one that is a VM) had a fatal cluster error
--- but it was only because I had neglected to re-create the RDMs
after migrating the data. So, when I tried to migrate something to
this server as a test, it freaked out.

Basically everything  worked flawlessly -- I must say it was the
fastest/cleanest data migration I have seen. Lovely.

Peter

On Sun, May 4, 2008 at 4:13 PM, Alister Leask <awleask <at> gmail.com> wrote:
> When I've done this in the past I have always removed the storage
>  before I deleted the old partition from the mirror group - that way I
>  was always sure that I was deleting the correct partition.
>
>  Pete, maybe I missed it previously but I'm not sure that you mentioned
>  clusters. You need to either mirror the SBD partition (can't be done
>  from NSSMU, IIRC) or shutdown the cluster and recreate the SBD on the
>  new storage. I've used the technique when recreating the cluster
>  partition of only presenting the LUN that will hold the SBD to the
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alister Leask | 5 May 2008 03:22
Picon

Re: 2 SANs, 2 LUNS, mirrored! YA!

Nice one Peter!

It does work well - but, when you have been expanding volumes for a
few years - trust me - there can be a lot of partitions to mirrors!

On Mon, May 5, 2008 at 12:00 PM, Peter Van Lone <petervl <at> gmail.com> wrote:
> Allister ...
>
>  I went ahead and braved it -- the interface is actually pretty clear
>  in NSSMU and the only way I could see messing it up (now that I've
>  done it 8 times) is to slip and move the selection accidentally, or
>  just not paying attention.
>
>  As for the cluster -- yes, it was clustered and my SBD was one
>  partition amongst 3 on one LUN -- I just mirrored/broke the mirror
>  like every other partition. The only consequence was that one of the
>  three cluster servers (the one that is a VM) had a fatal cluster error
>  --- but it was only because I had neglected to re-create the RDMs
>  after migrating the data. So, when I tried to migrate something to
>  this server as a test, it freaked out.
>
>  Basically everything  worked flawlessly -- I must say it was the
>  fastest/cleanest data migration I have seen. Lovely.
>
>  Peter
>
>
>
>
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Peter Van Lone | 5 May 2008 04:03
Picon

Re: 2 SANs, 2 LUNS, mirrored! YA!

hehe -- you bet. I can imagine it getting ugly quickly. It's too bad
that we cannot mirror pools -- now THAT would make things easier ...

P

On Sun, May 4, 2008 at 8:22 PM, Alister Leask <awleask <at> gmail.com> wrote:
> Nice one Peter!
>
>  It does work well - but, when you have been expanding volumes for a
>  few years - trust me - there can be a lot of partitions to mirrors!
>
>
>
>  On Mon, May 5, 2008 at 12:00 PM, Peter Van Lone <petervl <at> gmail.com> wrote:
>  > Allister ...
>  >
>  >  I went ahead and braved it -- the interface is actually pretty clear
>  >  in NSSMU and the only way I could see messing it up (now that I've
>  >  done it 8 times) is to slip and move the selection accidentally, or
>  >  just not paying attention.
>  >
>  >  As for the cluster -- yes, it was clustered and my SBD was one
>  >  partition amongst 3 on one LUN -- I just mirrored/broke the mirror
>  >  like every other partition. The only consequence was that one of the
>  >  three cluster servers (the one that is a VM) had a fatal cluster error
>  >  --- but it was only because I had neglected to re-create the RDMs
>  >  after migrating the data. So, when I tried to migrate something to
>  >  this server as a test, it freaked out.
>  >
>  >  Basically everything  worked flawlessly -- I must say it was the
(Continue reading)

Permalink | Reply | 2 comments |

Gmane