Provided by: manpages-dev_6.7-2_all bug

NAME

       bdflush - start, flush, or tune buffer-dirty-flush daemon

SYNOPSIS

       #include <sys/kdaemon.h>

       [[deprecated]] int bdflush(int func, long *address);
       [[deprecated]] int bdflush(int func, long data);

DESCRIPTION

       Note:  Since  Linux 2.6, this system call is deprecated and does nothing.  It is likely to
       disappear altogether in  a  future  kernel  release.   Nowadays,  the  task  performed  by
       bdflush() is handled by the kernel pdflush thread.

       bdflush()  starts,  flushes,  or  tunes  the buffer-dirty-flush daemon.  Only a privileged
       process (one with the CAP_SYS_ADMIN capability) may call bdflush().

       If func is negative or 0, and no daemon has been started, then bdflush() enters the daemon
       code and never returns.

       If func is 1, some dirty buffers are written to disk.

       If  func  is  2  or more and is even (low bit is 0), then address is the address of a long
       word, and the tuning parameter numbered (func-2)/2 is  returned  to  the  caller  in  that
       address.

       If  func  is 3 or more and is odd (low bit is 1), then data is a long word, and the kernel
       sets tuning parameter numbered (func-3)/2 to that value.

       The set of parameters, their values, and their valid  ranges  are  defined  in  the  Linux
       kernel source file fs/buffer.c.

RETURN VALUE

       If  func  is  negative  or  0 and the daemon successfully starts, bdflush() never returns.
       Otherwise, the return value is 0 on success and -1 on failure, with errno set to  indicate
       the error.

ERRORS

       EBUSY  An  attempt  was  made  to  enter the daemon code after another process has already
              entered.

       EFAULT address points outside your accessible address space.

       EINVAL An attempt was made to read or write an invalid parameter number, or  to  write  an
              invalid value to a parameter.

       EPERM  Caller does not have the CAP_SYS_ADMIN capability.

STANDARDS

       Linux.

HISTORY

       Since glibc 2.23, glibc no longer supports this obsolete system call.

SEE ALSO

       sync(1), fsync(2), sync(2)