public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: sync_file_range.2:  add some big WARNINGS
Date: Sat, 9 Jan 2010 15:49:10 +0100	[thread overview]
Message-ID: <20100109144910.GA30167@lst.de> (raw)
In-Reply-To: <20090827180116.GB31605-jcswGhMUV9g@public.gmane.org>

Are you going to put this or some equivalent note in?   Currently the
manpages is extremly dangerous as it doesn't warn people about this
system call not actually guaranteeing any data integrity.

On Thu, Aug 27, 2009 at 08:01:16PM +0200, Christoph Hellwig wrote:
> This system call is by design completely unsuitable for any data
> integrity operations.  Make that very clear in the manpage.
> 
> 
> Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
> 
> Index: man-pages/man2/sync_file_range.2
> ===================================================================
> --- man-pages.orig/man2/sync_file_range.2	2009-08-27 14:51:51.373360594 -0300
> +++ man-pages/man2/sync_file_range.2	2009-08-27 14:57:35.213854927 -0300
> @@ -80,11 +80,22 @@ after performing any write.
>  Specifying
>  .I flags
>  as 0 is permitted, as a no-op.
> -.SS Some details
> -None of these operations write out the file's metadata.
> +.SS WARNING
> +This system call is extremly dangerous and should not be used in portable
> +programs.  None of these operations write out the file's metadata.
>  Therefore, unless the application is strictly performing overwrites of
> -already-instantiated disk blocks,
> -there are no guarantees that the data will be available after a crash.
> +already-instantiated disk blocks, there are no guarantees that the data will
> +be available after a crash.  There is no user interface to know if a
> +write is purely an overwrite. On filesystem using copy on write semantics
> +like
> +.IR btrfs
> +an over write of existing allocated blocks is impossible.  Writing into
> +pre-allocated space many filesystems also require calls into the block
> +allocator which this system call does not sync out to disk.
> +This system call does not flush disk write caches and thus does not provide
> +any data integrity on systems with volatile disk write caches.
> +
> +.SS Some details
>  
>  .B SYNC_FILE_RANGE_WAIT_BEFORE
>  and
---end quoted text---
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2010-01-09 14:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-27 18:01 sync_file_range.2: add some big WARNINGS Christoph Hellwig
     [not found] ` <20090827180116.GB31605-jcswGhMUV9g@public.gmane.org>
2009-09-20  5:34   ` Michael Kerrisk
     [not found]     ` <cfd18e0f0909192234l57ad4ec0rda34dcb83e355c5e-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-09-21 20:15       ` Andrew Morton
     [not found]         ` <20090921131519.875b4608.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2009-09-22 11:40           ` Christoph Hellwig
     [not found]             ` <20090922114052.GA1521-jcswGhMUV9g@public.gmane.org>
2009-09-22 18:47               ` Andrew Morton
2009-09-30 15:47               ` Christoph Hellwig
2009-12-04 15:25   ` Christoph Hellwig
2010-01-09 14:49   ` Christoph Hellwig [this message]
     [not found]     ` <20100109144910.GA30167-jcswGhMUV9g@public.gmane.org>
2010-01-17  5:48       ` Michael Kerrisk
     [not found]         ` <cfd18e0f1001162148w78c3ebe8u9d54fdeb7dac8892-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-01-17  9:58           ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100109144910.GA30167@lst.de \
    --to=hch-jcswghmuv9g@public.gmane.org \
    --cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox