try_to_writeback_inodes_sb_nr(9) [centos man page]

TRY_TO_WRITEBACK_INO(9) 					   The Linux VFS					   TRY_TO_WRITEBACK_INO(9)

NAME

       try_to_writeback_inodes_sb_nr - try to start writeback if none underway

SYNOPSIS

       int try_to_writeback_inodes_sb_nr(struct super_block * sb, unsigned long nr, enum wb_reason reason);

ARGUMENTS

       sb
	   the superblock

       nr
	   the number of pages to write

       reason
	   the reason of writeback

DESCRIPTION

       Invoke writeback_inodes_sb_nr if no writeback is currently underway. Returns 1 if writeback was started, 0 if not.

COPYRIGHT

Kernel Hackers Manual 3.10					     June 2014						   TRY_TO_WRITEBACK_INO(9)

vxiod(7)						 Miscellaneous Information Manual						  vxiod(7)

NAME

       vxiod - Veritas Volume Manager I/O daemon process control device

DESCRIPTION

       The vxiod device in Veritas Volume Manager (VxVM) is used to control the number of volume I/O daemons active on the system.  A process con-
       text is necessary to implement the plex consistency recovery and writeback error handling policies for multi-plex volumes, and for continu-
       ing  normal  I/O  after a log write if the volume has logging enabled.  It is also required for the plex recovery performed with a mirrored
       volume in the read/writeback mode.

       There are three aspects of I/O daemon operations:

	    o	 General I/O

	    o	 Error handling

	    o	 Log handling

       I/O handling is achieved by an ioctl command that does not return, but instead calls the vxiod routine to wait for errors or  I/O  requests
       and  process  them.  When an error occurs, if there are no I/O daemons active, the I/O simply turns into a failure on that plex.  If a gen-
       eral I/O request is queued up when no daemons exist, then the I/O will hang forever until a daemon process is created.  If I/O daemons  are
       active,	then  the I/O is put on a work queue and the daemons are awakened.  A daemon takes an error request and tries to read other plexes
       until a read succeeds or all plexes have been tried.  Then, if the writeback facility is enabled, the daemon tries to write the	good  data
       to  each  plex  that  failed on the read.  If the write is successful, the read error is nullified.  An I/O request is handled in a similar
       manner.

       Logging is handled in a similar manner. An ioctl command, which does not return, is issued to create a daemon for  each	volume	which  has
       logging	enabled.  This	daemon	monitors  two  queues:	one queue of I/O which was started while the log was busy (the ``log'' queue), and
       another queue of requests which have been logged and now need to be started (the ``ready'' queue).  I/O requests are  taken  from  the  log
       queue  when  the log is no longer busy, and another log write is started.  Completion of a log write results in all I/O requests which have
       just been logged being placed on the I/O daemon's ready queue where they are immediately started.

       One mechanism finds out how many I/O error daemons are running, and another mechanism allows a process to become an I/O daemon.	 Before  a
       process	becomes  an  I/O  daemon,  it should close all open files and detach from the controlling tty.	An I/O or logging daemon cannot be
       killed except through an explicit ioctl.

FILES

       /dev/vx/iod		     vxiod control device

SEE ALSO

       vxiod(1M), ioctl(2)

VxVM 5.0.31.1							    24 Mar 2008 							  vxiod(7)