Re: holding disk too small? -- holding disk RAID configuration
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
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
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
