Re: holding disk too small? -- holding disk RAID configuration

[Gene Heskett]

On Wednesday 25 December 2019 19:33:04 Jon LaBadie wrote:

> On Mon, Dec 23, 2019 at 11:51:11PM -0500, Gene Heskett wrote:
> > On Monday 23 December 2019 21:16:26 Nathan Stratton Treadway wrote:
> > > On Sun, Dec 22, 2019 at 11:47:21 -0500, Gene Heskett wrote:
> > > > The first, /dev/sda contains the current operating system. This
> > > > includes /usr/dumps as a holding disk area.
>
> ...
>
> > Sounds good, so I'll try it.
>
> If the sda DLE(s) are small enough to go direct to "tape",
> define all holdings, but run sda DLEs with "holdingdisk no".
>

Some are rather gargantuan with multiple iso's etc. , so moving the 
holding disk to an otherwise unused spindle makes the best situation by 
my reasoning.  And backup times the last 2 nights have been cut 
drastically. The question then is will it work that well for 2 weeks. Or 
a month?

> > Merry Christamas everybody.
>
> mega-dittos!

Same here as I'm celebrating yet another instance of makeing the guy with 
the scythe blink. Twice now. But my non-oem parts list is beginning to 
read like the 6 million dollar man. But in the middle of all that work 
in the cath-lab at Ruby in Morgantown, my drivers license expired so I 
need to go get that fixed tomorrow. A week past a new Aortic valve in my 
ticker, I feel like I ought to be good for another decade.  Great IOW.

Copyright 2019 by Maurice E. Heskett
Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: holding disk too small? -- holding disk RAID configuration

[Jon LaBadie]

On Mon, Dec 23, 2019 at 11:51:11PM -0500, Gene Heskett wrote:
> On Monday 23 December 2019 21:16:26 Nathan Stratton Treadway wrote:
> 
> > On Sun, Dec 22, 2019 at 11:47:21 -0500, Gene Heskett wrote:
> > > The first, /dev/sda contains the current operating system. This
> > > includes /usr/dumps as a holding disk area.
> > >
...
> 
> Sounds good, so I'll try it.
> 
If the sda DLE(s) are small enough to go direct to "tape",
define all holdings, but run sda DLEs with "holdingdisk no".


> Merry Christamas everybody.

mega-dittos!

-- 
Jon H. LaBadie j...@jgcomp.com
 11226 South Shore Rd.  (703) 787-0688 (H)
 Reston, VA  20190  (703) 935-6720 (C)

Re: holding disk too small? -- holding disk RAID configuration

[Gene Heskett]

On Monday 23 December 2019 23:51:11 Gene Heskett wrote:

> On Monday 23 December 2019 21:16:26 Nathan Stratton Treadway wrote:
> > On Sun, Dec 22, 2019 at 11:47:21 -0500, Gene Heskett wrote:
> > > The first, /dev/sda contains the current operating system. This
> > > includes /usr/dumps as a holding disk area.
> > >
> > > The next box of rust, /dev/sdb, is the previous os, kept in case I
> > > need to go get something I forgot to copy over when I first made
> > > the present install. It also contains this /user/dumps directory
> > > but currently unused as it normally isn't mounted.
> > >
> > > Wash, rinse and repeat for /dev/sdc. normally not mounted.
> >
> > [...]
> >
> > > What would be the effect of moving from a single holding area on
> > > /dev/sda as it is now operated, compared to mounting and using the
> > > holding directorys that already exist on /dev/sdb and /dev/sdc?
> > > Seems to me this
> >
> > Right... mount the sdb and sdc holding-disk filesystems, then add
> > additional holdingdisk{} definitions pointing to those directories
> > to your amanda.conf.
> >
> > > should result in less pounding on the /dev/sda seek mechanism
> > > while backing up /dev/sda as it would move those writes to a
> > > different spindle, with less total time spent seeking overall.
> > >
> > > Am I on the right track?  How does amanda determine which holding
> > > disk area to use for a given DLE in that case?
> >
> > Yes, I think that's the right track.
> >
> > I have not investigated this in depth, but as far as I know Amanda
> > doesn't have a way to notice that a particular DLE is on physical
> > device local-sda and that a particular holding-disk directory is
> > also on that same physical device, and thus choose to use a
> > different holding disk for that particular DLE.  (It does attempt to
> > spread out temporary files across the various holding-disk
> > directories -- it just presumably can't take into account the
> > physical device origin of a particular DLE when decided where to
> > send that DLEs temporary file.)
> >
> > So if you left your existing holding-disk definition as well as
> > adding the ones for sdb and sdc, about one third of the time
> > (theoretically) Amanda would end up using sda for the holding disk
> > for the
> > os-files-on-sda's DLE, and you'd end up with some thrashing.  As far
> > as I know, the only way to completely avoid that is to to remove the
> > holdingdisk section pointing to sda from the config and use only the
> > other two.
> >
> > However, as long as you are using more than two dumpers in your
> > config, I'm pretty sure that having more than two physical drives in
> > use for holding disks will still come out ahead, because there will
> > also be some thrashing between the holding-disk files for different
> > DLEs that are being backed up in parallel.  So unless the server's
> > sda DLE was a huge portion of the overall data being backed up
> > across your entire disklist, I'd guess that the occasional thrashing
> > on sda when backing up that DLE is a price worth paying to have the
> > holdingdisk activity spread across as many physical drives as
> > possible.
> >
> > (Of course it wouldn't be a bad idea to try it for a dumpcycle with
> > three holding-disk drives and then comment out the entry for the
> > holding disk on sda and try that for a few runs at least and see how
> > the performance compares in reality on your actual installation...)
> >
> >
> > Nathan
>
> Sounds good, so I'll try it.

Except when I mouunted the sdc, it turned out to be the old 1T 
for /amandatapes, and its to close to launch time to go thru all the 
formatting. So we'll try with 1 holding disks, removeing /dev/sda.
 
> Also, where is the best explanation 
> for "bumpmult"? I don't seem to be getting the results I expect.
>
> Merry Christamas everybody.
>
> > 
> >-- -- Nathan Stratton Treadway  -  natha...@ontko.com  - 
> > Mid-Atlantic region Ray Ontko & Co.  -  Software consulting services
> >  -
> > http://www.ontko.com/ GPG Key:
> > http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239 Key
> > fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239
>
> Copyright 2019 by Maurice E. Heskett
> Cheers, Gene Heskett



Copyright 2019 by Maurice E. Heskett
Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: holding disk too small? -- holding disk RAID configuration

[Gene Heskett]

On Monday 23 December 2019 21:16:26 Nathan Stratton Treadway wrote:

> On Sun, Dec 22, 2019 at 11:47:21 -0500, Gene Heskett wrote:
> > The first, /dev/sda contains the current operating system. This
> > includes /usr/dumps as a holding disk area.
> >
> > The next box of rust, /dev/sdb, is the previous os, kept in case I
> > need to go get something I forgot to copy over when I first made the
> > present install. It also contains this /user/dumps directory but
> > currently unused as it normally isn't mounted.
> >
> > Wash, rinse and repeat for /dev/sdc. normally not mounted.
>
> [...]
>
> > What would be the effect of moving from a single holding area on
> > /dev/sda as it is now operated, compared to mounting and using the
> > holding directorys that already exist on /dev/sdb and /dev/sdc?
> > Seems to me this
>
> Right... mount the sdb and sdc holding-disk filesystems, then add
> additional holdingdisk{} definitions pointing to those directories to
> your amanda.conf.
>
> > should result in less pounding on the /dev/sda seek mechanism while
> > backing up /dev/sda as it would move those writes to a different
> > spindle, with less total time spent seeking overall.
> >
> > Am I on the right track?  How does amanda determine which holding
> > disk area to use for a given DLE in that case?
>
> Yes, I think that's the right track.
>
> I have not investigated this in depth, but as far as I know Amanda
> doesn't have a way to notice that a particular DLE is on physical
> device local-sda and that a particular holding-disk directory is also
> on that same physical device, and thus choose to use a different
> holding disk for that particular DLE.  (It does attempt to spread out
> temporary files across the various holding-disk directories -- it just
> presumably can't take into account the physical device origin of a
> particular DLE when decided where to send that DLEs temporary file.)
>
> So if you left your existing holding-disk definition as well as adding
> the ones for sdb and sdc, about one third of the time (theoretically)
> Amanda would end up using sda for the holding disk for the
> os-files-on-sda's DLE, and you'd end up with some thrashing.  As far
> as I know, the only way to completely avoid that is to to remove the
> holdingdisk section pointing to sda from the config and use only the
> other two.
>
> However, as long as you are using more than two dumpers in your
> config, I'm pretty sure that having more than two physical drives in
> use for holding disks will still come out ahead, because there will
> also be some thrashing between the holding-disk files for different
> DLEs that are being backed up in parallel.  So unless the server's sda
> DLE was a huge portion of the overall data being backed up across your
> entire disklist, I'd guess that the occasional thrashing on sda when
> backing up that DLE is a price worth paying to have the holdingdisk
> activity spread across as many physical drives as possible.
>
> (Of course it wouldn't be a bad idea to try it for a dumpcycle with
> three holding-disk drives and then comment out the entry for the
> holding disk on sda and try that for a few runs at least and see how
> the performance compares in reality on your actual installation...)
>
>
>   Nathan

Sounds good, so I'll try it.  Also, where is the best explanation 
for "bumpmult"? I don't seem to be getting the results I expect.

Merry Christamas everybody.
>
> --
>-- Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic
> region Ray Ontko & Co.  -  Software consulting services  -  
> http://www.ontko.com/ GPG Key:
> http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239 Key
> fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239



Copyright 2019 by Maurice E. Heskett
Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: holding disk too small? -- holding disk RAID configuration

[Nathan Stratton Treadway]

On Sun, Dec 22, 2019 at 11:47:21 -0500, Gene Heskett wrote:
> The first, /dev/sda contains the current operating system. This 
> includes /usr/dumps as a holding disk area.
> 
> The next box of rust, /dev/sdb, is the previous os, kept in case I need 
> to go get something I forgot to copy over when I first made the present 
> install. It also contains this /user/dumps directory but currently 
> unused as it normally isn't mounted.
> 
> Wash, rinse and repeat for /dev/sdc. normally not mounted.

[...] 

> What would be the effect of moving from a single holding area on /dev/sda 
> as it is now operated, compared to mounting and using the holding 
> directorys that already exist on /dev/sdb and /dev/sdc? Seems to me this 

Right... mount the sdb and sdc holding-disk filesystems, then add
additional holdingdisk{} definitions pointing to those directories to
your amanda.conf.

> should result in less pounding on the /dev/sda seek mechanism while 
> backing up /dev/sda as it would move those writes to a different 
> spindle, with less total time spent seeking overall.
> 
> Am I on the right track?  How does amanda determine which holding disk 
> area to use for a given DLE in that case?

Yes, I think that's the right track.

I have not investigated this in depth, but as far as I know Amanda
doesn't have a way to notice that a particular DLE is on physical device
local-sda and that a particular holding-disk directory is also on that
same physical device, and thus choose to use a different holding disk
for that particular DLE.  (It does attempt to spread out temporary files
across the various holding-disk directories -- it just presumably can't
take into account the physical device origin of a particular DLE when
decided where to send that DLEs temporary file.)

So if you left your existing holding-disk definition as well as adding
the ones for sdb and sdc, about one third of the time (theoretically)
Amanda would end up using sda for the holding disk for the
os-files-on-sda's DLE, and you'd end up with some thrashing.  As far as
I know, the only way to completely avoid that is to to remove the
holdingdisk section pointing to sda from the config and use only the
other two.

However, as long as you are using more than two dumpers in your config,
I'm pretty sure that having more than two physical drives in use for
holding disks will still come out ahead, because there will also be some
thrashing between the holding-disk files for different DLEs that are
being backed up in parallel.  So unless the server's sda DLE was a huge
portion of the overall data being backed up across your entire disklist,
I'd guess that the occasional thrashing on sda when backing up that DLE
is a price worth paying to have the holdingdisk activity spread across
as many physical drives as possible.

(Of course it wouldn't be a bad idea to try it for a dumpcycle with
three holding-disk drives and then comment out the entry for the holding
disk on sda and try that for a few runs at least and see how the
performance compares in reality on your actual installation...)


Nathan


Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239

Re: holding disk too small? -- holding disk RAID configuration

[Gene Heskett]

On Thursday 05 December 2019 16:16:58 Nathan Stratton Treadway wrote:

> On Tue, Dec 03, 2019 at 15:43:10 +0100, Stefan G. Weichinger wrote:
> > I consider recreating that holding disk array (currently RAID1 of 2
> > disks) as RAID0 ..
>
> Just focusing on this one aspect of your question: assuming the
> filesystem in question doesn't have anything other than the Amanda
> holding-disk area on it, I suspect you would be better off creating
> two separate filesystems, one on each underlying disk, rather than
> making them into a RAID0 array.
>
> Amanda can make use of two separate holding-disk directories in
> parallel, so you can still get twice the total holding disk size
> avilable in a run (compared to the current RAID1 setup), but Ananda's
> parallel accesses will probably cause less contention on the physical
> device since each filesystem is stored independently on one drive.
>
>
> (Also, if one of the drives fails the other holding disk filesystem
> will still be available, while if you are using RAID0 one drive
> failing will take out the whole array)
>
>   Nathan

I find this an interesting concept Nathan, and would like to explore it 
further.

In my setup here, serving this machine and 4 others in my machine shop 
menagery (sp?), I have 4 boxes of spinning rust.

The first, /dev/sda contains the current operating system. This 
includes /usr/dumps as a holding disk area.

The next box of rust, /dev/sdb, is the previous os, kept in case I need 
to go get something I forgot to copy over when I first made the present 
install. It also contains this /user/dumps directory but currently 
unused as it normally isn't mounted.

Wash, rinse and repeat for /dev/sdc. normally not mounted.

/dev/sdd is /amandatapes, mounted full time,

(I find keeping a disk spinning results is disks that last 100,000+ hours 
with no increase in error rates, I have a 1T that had 25 bad, 
reallocated sectors the first time I checked it at about 5k hours in 
2006, still has the same 25 reallocated sectors today at about 100,000 
head flying hours.)

What would be the effect of moving from a single holding area on /dev/sda 
as it is now operated, compared to mounting and using the holding 
directorys that already exist on /dev/sdb and /dev/sdc? Seems to me this 
should result in less pounding on the /dev/sda seek mechanism while 
backing up /dev/sda as it would move those writes to a different 
spindle, with less total time spent seeking overall.

Am I on the right track?  How does amanda determine which holding disk 
area to use for a given DLE in that case?

Thanks.

> --
>-- Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic
> region Ray Ontko & Co.  -  Software consulting services  -  
> http://www.ontko.com/ GPG Key:
> http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239 Key
> fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239



Copyright 2019 by Maurice E. Heskett
Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: holding disk too small? -- holding disk RAID configuration

[Nathan Stratton Treadway]

On Tue, Dec 03, 2019 at 15:43:10 +0100, Stefan G. Weichinger wrote:
> I consider recreating that holding disk array (currently RAID1 of 2
> disks) as RAID0 ..

Just focusing on this one aspect of your question: assuming the
filesystem in question doesn't have anything other than the Amanda
holding-disk area on it, I suspect you would be better off creating two
separate filesystems, one on each underlying disk, rather than making
them into a RAID0 array.

Amanda can make use of two separate holding-disk directories in
parallel, so you can still get twice the total holding disk size
avilable in a run (compared to the current RAID1 setup), but Ananda's
parallel accesses will probably cause less contention on the physical
device since each filesystem is stored independently on one drive.


(Also, if one of the drives fails the other holding disk filesystem will
still be available, while if you are using RAID0 one drive failing will
take out the whole array)

Nathan


Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239