[[ !!! PLEASE PLEASE -- KEEP THE CONVERSATION ON THE LIST
It is not my job to answer these questions. Other more
knowledgeable people on the list might jump in, and, they
may even point out mistakes in my answer! ]]
On 2006-07-10 15:54, silpa kala wrote:
Hi,
Thanks for ur information.I need some more
clarifications.
What is the input of chunker ? why the chunker is
necessary?
The input of the chunker is the backup data.
Chunker writes this data to holdingdisk in small
pieces. The main reason is that some filesystems cannot
have files larger than 2 (or 4) Gigabyte.
You may also have many holdingdisk, and chunker will
write the chunks spread over the holdingdisk, not being
limited by the size of one holdingdisk.
In Amanda 2.4.5 and earlier, there was no "chunker"
process: in those releases this feature was built in
to dumper (see below).
what is the input of dumper ? what is the output of
dumper?
For each backup, a "dumper" gets the instructions from
driver to start that particular backup.
There are many dumpers operating in parallel, each
doing one disk-list-entry (DLE) at a time.
The dumper is responsible to contact the client
and get the backup started there.
There is no real output of dumper, except the status
of the backup when it is finished, which it communicates
to driver. (So that driver can make an intellegent
decision what to do next.)
The purpose of a dumper program is to supervise the backup
of one single disk-list-entry.
Because Amanda starts many dumpers at once, there are many
backups in progress at once too.
TCP ports are used to connect transfer the data.
(??I'm afraid I do not really understand "to connect transfer"...)
Yes, the data is transferred using a TCP connection.
Whether which module is used for the socket connection
at the client side?
(??What do you mean by "module"?)
The server program "dumper" connects to the amanda UDP port
10080 and requests a "sendbackup".
The server also sends a list of 2 or 3 TCP portnumbers
containing the DATA, MESG (+error), and, if index was
asked another one for the INDEX datastream.
The client executes the correct handling program (for gnutar or
for dump), making sure the stdout is connected to the DATA
tcp port, and stderr is connected to the MESG tcp port and,
if indexing is needed, the data-stream is actually duplicated
with a tee-like mechanism, and fed in the gnutar/restore program
with a table-of-contents option. The output of that stream is
then connected to the tcp port that the server asked for the INDEX
stream.
Suppose if the backup size more than 65535 bytes. How
the client module will send the backup? whether the
backup data is divided into more than one packet.
Please clarify ?
This buffer size has nothing to do with the size of the
backup. The send and receive buffer is a property of a TCP
connection. (Phew! are you really sure you want to reorganize
the socket code in Amanda?)
Thanks In advance.
--
Paul Bijnens, xplanation Technology Services Tel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM Fax +32 16 397.512
http://www.xplanation.com/ email: Paul.Bijnens AT xplanation DOT com
***********************************************************************
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***********************************************************************
|
