Imported Upstream version 3.1.0
[debian/amanda] / perl / Amanda / Device.pod
1 /*
2  * Copyright (c) 2009, 2010 Zmanda, Inc.  All Rights Reserved.
3  *
4  * This program is free software; you can redistribute it and/or modify it
5  * under the terms of the GNU General Public License version 2 as published
6  * by the Free Software Foundation.
7  *
8  * This program is distributed in the hope that it will be useful, but
9  * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
10  * or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
11  * for more details.
12  *
13  * You should have received a copy of the GNU General Public License along
14  * with this program; if not, write to the Free Software Foundation, Inc.,
15  * 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
16  *
17  * Contact information: Zmanda Inc., 465 S. Mathilda Ave., Suite 300
18  * Sunnyvale, CA 94085, USA, or: http://www.zmanda.com
19  */
20
21 %perlcode %{
22
23 =head1 NAME
24
25 Amanda::Device - interact with Amanda data-storage devices
26
27 =head1 SYNOPSIS
28
29   use Amanda::Device qw( :constants );
30
31   my $dev = Amanda::Device->new($device_name);
32   if ($dev->read_label() == $DEVICE_STATUS_SUCCESS) {
33       print "Label on $device_name is '$dev->volume_label'\n";
34   }
35
36 =head1 DATA MODEL
37
38 A volume is a container for data which can be "loaded" into a particular
39 device. For tape devices, a volume is a tape, but most other devices do not
40 deal with such physical objects. Each volume has a volume header giving, among
41 other things, the label of the volume and the timestamp on which it was
42 written. The header may also indicate that the volume is not an Amanda volume.
43 Aside from the header, a volume contains a sequence of files, numbered starting
44 at 1. While writing, devices number files sequentially, but devices that
45 support partial volume recycling may have "holes" in the sequence of file
46 numbers where files have been deleted. The C<seek_file> method, below,
47 describes how the API represents this situation. Each file has a header, too,
48 which contains lots of information about the file. See L<Amanda::Header> for
49 the full list. After the header, a file is just a sequence of bytes.
50
51 Reads and writes to devices take place in blocks. Unlike a typical
52 operating-system file, in which any block boundaries are lost after the file is
53 written, devices must be read back with the block sizes that were used to read.
54 See C<amanda-devices(7)> for more in block sizes, and the read_block and
55 write_block sections, below, for more information.
56
57 =head1 USING THE DEVICE API
58
59 The Device API is object-oriented, so the first task in using the API is to
60 make a Device object:
61
62     $dev = Amanda::Device->new("tape:/dev/nst0");
63
64 This function takes a device name (possibly a device alias) and returns a
65 device object. This function always returns a Device, although it may be a Null
66 device with an error condition. Any C<new> call should be followed by a check
67 of the device's status:
68
69     $dev = Amanda::Device->new($device_name);
70     if ($dev->status() != $Amanda::Device::DEVICE_STATUS_SUCCESS) {
71       die "Could not open '$device_name': " . $dev->error();
72     }
73
74 This function does not access the underlying hardware or any other external
75 systems in any way: that doesn't happen until C<read_label> or C<start>.  An
76 Amanda configuration must be loaded when this function is called, as it
77 searches the configuation for device definitions.  The member variable
78 C<device_name> is set when this function has returned.
79
80 It is unusual for higher-level code to call C<< Amanda::Device->new >>.
81 Intead, use L<Amanda::Changer> to load a volume and reserve access to it; the
82 resulting reservation will contain an already-created Device object.
83
84 While Amanda proivdes multiple implementations of the Device class, they are
85 not distinguishable via the usual Perl methods (C<ref> or C<< $dev->isa >>).
86
87 Device users generally call device methods in the following order for reading:
88
89     read_label (optional)
90     start
91     seek_file (optional)
92     read_block (repeated)
93
94 or, when writing or appending:
95
96     read_label (optional)
97     start
98     start_file
99     write_block (repeated)
100     finish_file
101     finish
102
103 =head2 Alternate Constructor
104
105 To create a new RAIT device from a collection of device objects, call
106 C<< Amanda::Device->new_rait_from_children($child1, $child2, ..) >>.
107 If one of the child objects is C<undef>, the resulting RAIT device
108 will operate in degraded mode.
109
110 =head2 Error Handling
111
112 Device methods return a particular value to signal the presence of an error
113 condition. In many cases, this is simply false (exceptions are listed below).
114
115 When a device signals an error, C<< $dev->status >> and C<< $dev->error >>
116 contain details of what went wrong. Status is a bitfield where each bit that is
117 set indicates a possible problem. Unfortunately, some devices are unable to
118 distinguish states due to limitations of an external system. For example, the
119 tape device often cannot distinguish an empty drive
120 (C<$DEVICE_STATUS_VOLUME_MISSING>) from a hard device error
121 (C<$DEVICE_STATUS_DEVICE_ERROR>), leading to the status
122 C<$DEVICE_STATUS_VOLUME_MISSING>|C<$DEVICE_STATUS_DEVICE_ERROR>.  To be clear:
123 as few as one of the status bits may represent a actual problem.  If
124 C<$DEVICE_STATUS_VOLUME_UNLABELED> is set along with other bits, it is I<not>
125 safe to assume that an unlabeled volume is available.  However, if the bit is
126 not set, then it is safe to assume there is no unlabeled volume present.
127
128 =over 2
129
130 =item C<$DEVICE_STATUS_SUCCESS>
131
132 All OK (no bits set)
133
134 =item C<$DEVICE_STATUS_DEVICE_ERROR>
135
136 The device is in an unresolvable error state, and further retries are unlikely
137 to change the status
138
139 =item C<$DEVICE_STATUS_DEVICE_BUSY>
140
141 The device is in use, and should be retried later
142
143 =item C<$DEVICE_STATUS_VOLUME_MISSING>
144
145 The device itself is OK, but has no media loaded. This may change if media is
146 loaded by the user or a changer
147
148 =item C<$DEVICE_STATUS_VOLUME_UNLABELED>
149
150 The device is OK and media is laoded, but there is no Amanda header or an
151 invalid header on the media.
152
153 =item C<$DEVICE_STATUS_VOLUME_ERROR>
154
155 The device is OK, but there was an unresolvable error loading the header from
156 the media, so subsequent reads or writes will probably fail.
157
158 =back
159
160 At the risk of being repetitive, never test a device's status with C<==>,
161 unless it is to C<$DEVICE_STATUS_SUCCESS>. Furthermore, never try to parse the
162 device error messages -- they are only for user consumption, and may differ
163 from device to device.
164
165 In addition to the status bitfield, a Device also provides a
166 user-comprehensible error message, available from the methods C<error>
167 (returning the error message), C<status_error> (returning the string form of
168 the status), or C<status_or_error> (returning the error message if one is set,
169 otherwise the string form of the status). None of these functions will ever
170 return C<undef>.
171
172 =head2 Properties
173
174 Device properties provide a bidirectional means of communication between
175 devices and their users. A device provides values for some properties, which
176 other parts of Amanda can use to adjust their behavior to suit the device. For
177 example, Amanda will only attempt to append to a volume if the device's
178 properties indicate that it supports this activity. Some devices have
179 additional properties that can be set to control its activity. For example, the
180 S3 Device requires that the users' keys be given via properties.
181
182 See C<amanda-devices(7)> for more information on device properties and their
183 meanings.
184
185 The methods C<property_get> and C<property_set> are used to get and set
186 properties, respectively. If the indicated property simply does not exist,
187 these functions return an error indication (FALSE), but the device's status
188 remains C<$DEVICE_STATUS_SUCCESS>. If a more serious error occurs, then the
189 device's status is set appropriately.
190
191 Device properties are easy to handle, as the Perl-to-C glue takes care of all
192 necessary type conversions:
193
194     $success = $device->property_set("BLOCK_SIZE", $blocksize);
195     $blocksize = $device->property_get("BLOCK_SIZE");
196
197 If C<property_get> is called in an array context, it returns the property
198 value, its surety, and its source, in that order.  If there is an error
199 fetching the property, C<property_get> returns C<undef>.
200
201 The C<property_list()> method returns a list of all properties:
202
203   my @props = $device->property_list();
204
205 its return is an array of hashes:
206
207   ( { 'access' => $access_flags,
208       'name' => $property_name,
209       'description' => $property_description },
210     ...
211   )
212
213 =head3 Surety and Source
214
215 All properties have a source - where the value came from - and surety - a level
216 of confidence in the value. This can be used to decide which of two potentially
217 contradictory properties to believe. For example, the RAIT device examines the
218 source and surety of child devices' block sizes, prefering properties set by
219 the user (C<$PROPERTY_SOURCE_USER>) over others.
220
221 Set a property's source and surety with C<property_set_ex>:
222     $dev->property_set_ex("my_prop", 13, $PROPERTY_SURETY_BAD, $PROPERTY_SOURCE_DEFAULT);
223 The surety and source are returned after the property value in list context:
224     my ($val, $sur, $sou) = $dev->property_get("my_prop");
225
226 The available sureties are:
227
228   $PROPERTY_SURETY_GOOD
229   $PROPERTY_SURETY_BAD
230
231 and the sources are:
232
233   $PROPERTY_SOURCE_DEFAULT
234   $PROPERTY_SOURCE_DETECTED
235   $PROPERTY_SOURCE_USER
236
237 =head2 Concurrency
238
239 Some devices can perform more than one operation simultaneously, while others
240 are more limited. For example, a tape device is exclusive to a single process
241 while it is in use, while a VFS device can support concurrent reads and writes
242 on the same volume.
243
244 As of this writing, device locking is not correctly implemented in many
245 devices; consult the source code and check with the Amanda developers before
246 depending on concurrent operation of devices.
247
248 =head2 EOM and EOF
249
250 When writing to a volume, an EOM (end-of-media) condition occurs when no more
251 space is available on the volume.  Some devices (currently only those
252 supporting DirectTCP) distinguish a logical EOM (LEOM) from a physical EOM
253 (PEOM).  The logical EOM comes some distance before the physical EOM, with
254 enough space left to finish a data block and write any additional bookkeeping
255 data before PEOM.
256
257 In such devices, the C<is_eom> attribute is set once LEOM is detected.  Such
258 detection can happen in any method that writes to the volume, including
259 C<start>, C<start_file>, C<finish_file>, and C<finish>.  API users that
260 understand LEOM should take this as a signal to complete writing to the device
261 and move on before hitting PEOM.
262
263 Devices which do not support EOM simply return a VOLUME_ERROR when the volume
264 is full.  If this occurs during a C<write_block> operation, then the volume may
265 or may not contain the block - the situation is indeterminate.
266
267 =head2 Device Resources
268
269 Some device types have a "locking" mechanism that prevents other parts of the
270 system from accessing the underlying resource while an operation is in
271 progress.  For example, a typical UNIX tape driver cannot be opened by two
272 processes at once.
273
274 Amanda Devices will lock the underlying resource when C<start> or C<read_label>
275 is called, and unlock the resource either when the Device object is
276 garbage-collected or in the C<finish> method.  Thus in a calling sequence such as
277
278     read_label
279     start
280     seek_file
281     ...
282     finish
283
284 the underlying resource remains locked for the entire sequence, even between
285 read_label and finish.
286
287 It is unwise to rely on Perl's garbage-collection to automatically release
288 resources.  Instead, always explicitly release resources with a C<finish> call.
289 The Changer API is careful to do this in its C<release> method.
290
291 =head2 Member Variables
292
293 All member variables are implemented using accessor methods, rather than the
294 more common hashref technique.  Use
295
296   print $dev->device_name, "\n";
297
298 instead of
299
300   print $dev->{'device_name'}, "\n";
301
302 The member variables are:
303
304 =over 4
305
306 =item C<file>
307
308 the current file number, if any
309
310 =item C<block>
311
312 the current block number, if any
313
314 =item C<in_file>
315
316 true if the device is in the middle of reading or writing a file
317
318 =item C<device_name>
319
320 the name with which the device was constructed; note that this is not set until after open_device is finished -- it is an error to access this variable in an open_device implementation
321
322 =item C<access_mode>
323
324 the current access mode (C<$ACCESS_NULL>, or that supplied to start)
325
326 =item C<is_eof>
327
328 true if an EOF occurred while reading; also used by C<write_from_connection>
329
330 =item C<is_eom>
331
332 true if a write operation reached the end of the volume (end-of-medium)
333
334 =item C<volume_label>
335
336 the label of the current volume, set by start and read_label
337
338 =item C<volume_time>
339
340 the timestamp of the current volume, set by start and read_label
341
342 =item C<volume_header>
343
344 the header of the current volume, set by read_label
345
346 =item C<status>
347
348 the device's error status (bit flags) as an integer
349
350 =item C<status_error>
351
352 the device's error status (bit flags) as a string
353
354 =item C<error>
355
356 the device's error message
357
358 =item C<error_or_status>
359
360 the device's error message, if set, otherwise the same as C<status_error> --
361 use this to display error messages from devices
362
363 =item C<block_size>
364
365 the device's currently configured block size. This is also available via the
366 BLOCK_SIZE property. Writers should use block_size-byte blocks, and readers
367 should initially use block_size, and expand buffers as directed by
368 C<read_block>.
369
370 =item C<min_block_size>
371
372 minimum allowed block size for this device
373
374 =item C<max_block_size>
375
376 maximum allowed block size for this device
377
378 =back
379
380 =head2 Object Methods
381
382 =head3 configure($use_global_config)
383
384     $dev->configure(1);
385
386 Once you have a new device, you should configure it. This sets properties on
387 the device based on the user's configuation. If C<$use_global_config> is true,
388 then any global C<device_property> parameters are processed, along with
389 tapetype and other relevant parameters. Otherwise, only parameters from the
390 device definition (if the device was opened via an alias) are processed.
391
392 This method is I<deprecated>.  All access to Devices should be via the Changer
393 API (see L<Amanda::Changer>), which implements its own, more advanced method of
394 configuring devices.  The C<configure> method may be removed in a future
395 release.
396
397 =head3 read_label
398
399     $status = $dev->read_label();
400
401 This function reads the tape header of the current volume, returning the
402 Device's status (see "Error Handling", above). Since this is often the first
403 function to accses the underlying hardware, its error status is the one most
404 often reported to the user. In fact, C<amdevcheck(8)> is little more than a
405 wrapper around read_label.
406
407 The method sets the following member variables:
408
409 =over 4
410
411 =item C<volume_header>
412
413 if any header data was read from the volume, it is represented here. The
414 header's type may be F_WEIRD if the header was not recognized by Amanda.
415
416 =item C<volume_label>
417
418 if read_label read the header successfully, then volume_label contains the
419 label
420
421 =item C<volume_time>
422
423 smililarly, if read_label read the header successfully, then volume_time
424 contains the timestamp from the header
425
426 =back
427
428 =head3 start
429
430     $succss = $dev->start($ACCESS_WRITE, $label, $timestamp);
431
432 Start starts the device and prepares it for the use described by its second
433 parameter. This function can be called regardless of whether C<read_label> has
434 already been called.
435
436 If the access mode is C<$ACCESS_WRITE>, then the label and timestamp must be
437 supplied (although leaving the timestamp undef will use the current time), and
438 they will be used to write a new volume header. Otherwise, these parameters
439 should be undef.
440
441 On completion, start leaves the device's C<access_mode>, C<volume_label> and
442 C<volume_time> member variables set, by reading the tape header if necessary.
443 Note that in mode C<$ACCESS_APPEND>, the C<file> member variable is not set
444 until after C<start_file> has been called.
445
446 =head3 start_file
447
448  $success = $dev->start_file($header);
449
450 This method prepares the device to write data into a file, beginning by writing
451 the supplied header to the volume. On successful completion, the device's
452 C<file> is set to the current file number, C<block> is zero, and C<in_file> is
453 true.  If the volume is out of space, the C<is_eom> member is set to true and
454 the method returns false with status C<DEVICE_STATUS_VOLUME_ERROR>.
455
456 =head3 write_block
457
458  # (not available from Perl)
459  success = device_write_block(dev, blocksize, buf);
460
461 This method writes a single block of data to the volume.  It is only available
462 from C -- Perl code should not be handling raw data, as it is far too slow.
463 Use the transfer architecture (L<Amanda::Xfer>) for that purpose.
464
465 The C<blocksize> must be the device's block size, unless
466 this is a short write.  A short write must be the last block
467 of a file. Some devices will zero-pad a short write to a full
468 blocksize. This method returns false on error.  If the volume is
469 out of space, C<is_eom> is set and the method returns false with
470 status C<DEVICE_STATUS_VOLUME_ERROR>.  Note that not all devices can
471 differentiate an EOM condition from other errors; these devices will
472 set C<is_eom> whenever the situation is ambiguous.
473
474 This function ensures that C<block> is correct on exit. Even in an
475 error condition, it does not finish the current file for the caller.
476
477 =head3 write_from_fd (DEPRECATED)
478
479  my $qfd = Amanda::Device::queue_fd_t->new(fileno($fh));
480  if (!$dev->write_from_fd($fd)) {
481    print STDERR $qfd->{errmsg}, "\n" if ($qfd->{errmsg});
482    print STDERR $dev->status_or_error(), "\n" if ($dev->status());
483  }
484
485 This method reads from the given file descriptor until EOF, writing the data to
486 a Device file which should already be started, and not returning until the
487 operation is complete. The file is not automatically finished. This method is
488 deprecated; the better solution is to use the transfer architecture
489 (L<Amanda::Xfer>).
490
491 This is a virtual method, but the default implementation in the Device class
492 uses C<write_block>, so there is no need for subclasses to override it.
493
494 =head3 finish_file
495
496  $success = $dev->finish_file();
497
498 Once an entire file has been written, finish_file performs any
499 cleanup required on the volume, such as writing filemarks. On exit,
500 C<in_file> is false.  If the device runs out of space while finishing
501 (e.g., the filemark does not fit), then this method returns false
502 with status C<DEVICE_STATUS_VOLUME_ERROR> and C<is_eom> is set.
503
504 This function should not be used while reading -- instead, just seek
505 to the next file.
506
507 =head3 seek_file
508
509  $header = $dev->seek_file($fileno);
510
511 In C<$ACCESS_READ>, C<seek_file> sets up the device to read from file
512 C<$fileno>. This function is not available in C<$ACCESS_WRITE> and
513 C<$ACCESS_APPEND>. It returns the header from the requested file on success, or
514 undef on error.
515
516 If the requested file doesn't exist, as might happen when a volume has had
517 files recycled, then C<seek_file> will seek to the next file that does exist. The
518 file this function selected is indicated by the C<file> member variable on exit.
519 If the requested file number is exactly one more than the last valid file, this
520 function returns a C<$F_TAPEEND> header.
521
522 As an example, on a volume with only files 1 and 3:
523
524  $dev->seek_file(1) returns header for file 1, $dev->file == 1
525  $dev->seek_file(2) returns header for file 3, $dev->file == 3
526  $dev->seek_file(3) returns header for file 3, $dev->file == 3
527  $dev->seek_file(4) returns a tapend header, $dev->file == 4
528  $dev->seek_file(5) returns NULL/undef
529
530 On exit, C<is_eof> is false, C<in_file> is true unless no file was found (tapeend or NULL), C<file> is the discovered file, and C<block> is zero.
531
532 =head3 seek_block
533
534  $success = $dev->seek_block($block);
535
536 After seeking to a file, the caller can optionally seek to a particular block
537 in the file. This function will set C<block> appropriately. Note that it may
538 not be possible to detect EOF, so this function may fail to set C<is_eof> even
539 though a subsequent C<read_block> will return no data.
540
541 =head3 read_block
542
543  # (not available from Perl)
544  bytes_read = device_read_block(dev, buffer, *blocksize);
545
546 This method is the complement of C<write_block>, and reads the next block from
547 the device, or returns -1 on error. Pass a buffer and its size. If the buffer
548 is not big enough, no read is performed, the parameter C<blocksize> is set to
549 the required blocksize, and the method returns 0. As a special case, passing a
550 C<NULL> buffer and C<*blocksize == 0> is treated as a request for the required block
551 size. It is not an error to pass a buffer that is too large (and, in fact, this
552 is precisely the effect of setting the C<read_block_size> configuration
553 parameter).
554
555 On EOF, this method returns -1, but sets C<is_eof> and leaves the device's
556 status set to C<$DEVICE_STATUS_SUCCESS>. Some devices may be able to detect EOF
557 while reading the last block, and will set C<is_eof> at that time. Others must
558 wait for the next read to fail. It is never an error to call C<read_block>
559 after an EOF, so there is no need to check C<is_eof> except when C<read_block>
560 returns -1.
561
562 =head3 read_to_fd (DEPRECATED)
563
564  queue_fd_t *qfd = queue_fd_new(fd, NULL);
565  my $qfd = Amanda::Device::queue_fd_t->new(fileno($fh));
566  if (!$dev->read_to_fd($fd)) {
567    print STDERR $qfd->{errmsg}, "\n" if ($qfd->{errmsg});
568    print STDERR $dev->status_or_error(), "\n" if ($dev->status());
569  }
570
571 This method reads the current file from the device and writes to the given file
572 descriptor, not returning until the operation is complete. This method is
573 deprecated; new uses of devices use the transfer architecture
574 (L<Amanda::Xfer>).
575
576 This is a virtual method, but the default implementation in the Device class
577 uses C<read_block>, so there is no need for subclasses to override it.
578
579 =head3 finish
580
581  $success = $dev->finish();
582
583 This undoes the effects of start, returning the device to a neutral state
584 (C<$ACCESS_NULL>).  It will also release any resources acquired by
585 C<read_label>, even if C<start> was not called.  After C<finish>, it is not an
586 error to call C<start> again, even with a different mode.
587
588 =head3 recycle_file
589
590  $success = $dev->recycle_file(fileno);
591
592 On devices that support it, this removes the indicated file from the volume,
593 presumably freeing its space to be used for other files. File numbers of
594 existing files will not change, so this operation may leave "holes" in the
595 sequence of file numbers. See C<seek_file> to see how this is handled.
596
597 This method cannot be called while in a file, nor while in C<$ACCESS_READ>
598 mode.
599
600 =head3 erase
601
602  $success = $dev->erase(fileno);
603
604 On devices that support it, this erases all data from the volume, presumably
605 freeing the space.  This method must be called before start and after finish --
606 that is, while the device is in a neutral state (C<$ACCESS_NULL>). You can
607 detect whether or not this operation is supported using the C<full_deletion>
608 property.
609
610 =head3 eject
611
612  $success = $dev->eject();
613
614 On devices that support it, this eject the volume.  This method can be called
615 before start and after finish.
616
617 =head3 directtcp_supported
618
619   $supp = $dev->directtcp_supported();
620
621 This method returns TRUE if the DirectTCP-related methods (C<listen>,
622 C<accept>, C<write_from_connection>, and C<read_to_connection>) are implemented
623 by this device.
624
625 =head3 listen
626
627   $addrs = $dev->listen($for_writing);
628
629 The C<listen> method starts the device listening for an incoming DirectTCP
630 connection.  The method returns a set of IP:PORT pairs to which a TCP
631 connection can be made.  The boolean C<for_writing> is TRUE if
632 this connection will be used to write to the device.
633
634 This method can be called at any time, but between the time C<listen> is called
635 and when C<accept> returns, no other methods of the device should be called.
636
637 The return value might look like:
638
639   $addrs = [ [ "127.0.0.1", 9382 ] ]
640
641 In C, the memory for these addresses remains the responsibility of the device,
642 and will remain unchanged until C<accept> returns.
643
644 =head3 accept
645
646   $conn = $dev->accept();
647
648 This method accepts a connection to one of the addresses returned by C<listen>,
649 returning an established DirectTCPConnection object (see below).  It returns
650 C<undef> on failure.  Note that this method may block indefinitely if no
651 connection ever occurs.  The C implementation returns an already-referenced
652 connection object, so the caller should call C<g_object_unref> when the
653 connection is no longer needed.
654
655 =head3 use_connection
656
657   my $ok = $dev->use_connection($conn);
658
659 Call this method to use a DirectTCPConnection object created with another
660 device.  The method must be called before the device is started (so
661 C<access_mode> is C<$ACCESS_NULL>), as some devices cannot support switching
662 connections without rewinding.  Any subsequent C<read_from_connection> or
663 C<write_to_connection> calls will use this connection.
664
665 =head3 write_from_connection
666
667   ($ok, $actual_size) = $dev->write_from_connection($size);
668
669 This method reads data from the DirectTCPConnection specified with
670 C<use_connection> or returned from C<accept> and writes it to the volume.   It
671 writes at most C<$size> bytes, and returns the number of bytes written in
672 C<$actual_size>.  On error, C<$ok> is false.
673
674 When an EOF is received over the connection, signalling the end of the data
675 stream, then this method returns without error (C<$ok> is true), with
676 C<$actual_size> indicating the number of bytes written to the device (which may
677 be zero).  In this case, the C<is_eof> attribute is true on return.
678
679 Similarly, when the device encounters logical EOM in this method, it returns
680 the total bytes transferred in C<$actual_size>, with C<$ok> true, and the
681 C<is_eom> attribute true.  No data is lost.  If writes continue until physical
682 EOM, data may be lost.
683
684 =head3 read_to_connection
685
686   ($ok, $actual_size) = $dev->read_to_connection($size);
687
688 This method is similar to C<write_from_connection> but the data flows in the
689 opposite direction.  It reads at most C<$size> bytes, and returns the total
690 number of bytes read in C<$actual_size>.
691
692 When the method encounters an EOF, it stops early and returns successfully with
693 the number of bytes actually read (which may be zero).
694
695 =head3 property_get
696
697 Get a property value, where the property is specified by name.  See "Properties", above.
698
699 =head3 property_set
700
701 Set a simple property value.  See "Properties", above.
702
703 =head3 property_set_ex
704
705 Set a property value with surety and source.  See "Properties", above.
706
707 =head2 CONSTANTS
708
709 This module defines a large number of constant scalars.  These constants are
710 available from the package namespace (e.g., C<$Amanda::Device::ACCESS_WRITE>),
711 or imported with the C<:constant> import tag.
712
713 =head2 DirectTCPConnection objects
714
715 The C<accept> method returns an object to represent the ongoing DirectTCP
716 connection.  This object is mostly useful as a "token" to be passed to
717 C<write_from_connection> and C<read_to_connection>.  In particular, a
718 connection created by one device can be used with another device; this is how
719 DirectTCP dumps are spanned over multiple volumes.
720
721 The class does have one critical method, though:
722
723   $conn->close();
724
725 This method closes the connection, releasing all resources allocated to it.  It
726 can be called at any time, whether the remote side has closed the connection
727 already or not.
728
729 =cut
730
731 %}