All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Patrick J. LoPresti" <patl@curl.com>
To: linux-kernel@vger.kernel.org
Cc: Matthias Andree <matthias.andree@stud.uni-dortmund.de>
Subject: Re: [PATCH] 2.4.19-rc1/2.5.25 provide dummy fsync() routine for directories on NFS mounts
Date: 15 Jul 2002 10:49:46 -0400	[thread overview]
Message-ID: <s5gwurxt59x.fsf@egghead.curl.com> (raw)
In-Reply-To: <mit.lcs.mail.linux-kernel/20020715133507.GF32155@merlin.emma.line.org>

Matthias Andree <matthias.andree@stud.uni-dortmund.de> writes:

> We had a similar discussion along the lines of an MTA roughly a year
> ago, but without your (unquoted) objection that fsync() on a fiel
> without write permit should be impossible.

It was a long thread:

  http://groups.google.com/groups?threadm=linux.kernel.3B5FC7FB.D5AF0932%40zip.com.au

  http://lists.insecure.org/linux-kernel/2001/Aug/index.html#39

> The essence was that Linux 2.4 ext3fs and reiserfs guarantee that on
> fsync(), the file is recoverable from the place it was created, 2.2 was
> halfway there; but beware: only data=ordered or data=journal (in ext3fs,
> as beta patch for reiserfs from
> ftp.suse.com:/pub/people/mason/patches/data-logging/ <- from memory))
> will guarantee that your file contents are recoverable.

I do not recall anything about data=ordered or data=journal mode being
required.  I thought someone authoritative (Stephen Tweedie?) said
that ext3 happens to commit the journal on fsync(), independent of the
journaling mode, but that this behavior was an implementation
coincidence and not guaranteed.  (Unfortunately, I am having trouble
finding that message...  Can someone familiar with the source confirm
or deny this?)

I would love to know what IS guaranteed.  This fsync() question keeps
cropping up, and as far as I know there is no authoritative statement
anywhere about what Linux promises.  "Read the source code" is the
wrong answer; implementations can change at any time.  This is a
question about the interface, not the implementation.  "See post XXX
on linux-kernel" is almost as bad.

> That aside, it would really useful to get this "hog a writer" issue
> ironed out either way, and that the illogical "fsync() a O_RDONLY"
> file be resolved somehow.

It is a non-issue; no resolution is necessary.  If I can even read or
write a single file on the same DISK (or bus) that some server process
uses, I can "hog its resources" and slow it down.  Horrors!  Is there
any solution???  Oh yeah, don't let me do that.

The only interesting question here is what the relevant standards say.
And if they allow fsync() at all on a read-only descriptor, then there
is pretty clearly only one thing that can mean.  If you have a problem
with this behavior, then configure your precious servers to keep their
data unreadable by untrusted parties.

> Is fsync()ing directories any portable?

No, but apparently it is what Linux supports.  If this were documented
clearly somewhere, maybe application authors could be convinced to
support it.

 - Pat

  parent reply	other threads:[~2002-07-15 14:46 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-09 13:49 [PATCH] 2.4.19-rc1/2.5.25 provide dummy fsync() routine for directories on NFS mounts Trond Myklebust
2002-07-09 14:06 ` Richard B. Johnson
2002-07-09 14:06 ` Richard B. Johnson
2002-07-09 14:08   ` Trond Myklebust
2002-07-09 14:08   ` Trond Myklebust
2002-07-09 15:06     ` Richard B. Johnson
2002-07-09 15:06     ` Richard B. Johnson
2002-07-09 16:56       ` Alan Cox
2002-07-09 16:56         ` Alan Cox
2002-07-09 17:22         ` Richard B. Johnson
2002-07-09 17:22           ` Richard B. Johnson
2002-07-09 18:58           ` [NFS] " Bill Rugolsky Jr.
2002-07-09 18:58           ` Bill Rugolsky Jr.
2002-07-09 19:11           ` Alan Cox
2002-07-09 19:11             ` Alan Cox
2002-07-09 19:13             ` Richard B. Johnson
2002-07-09 19:13             ` Richard B. Johnson
2002-07-09 19:39               ` [PATCH] 2.4.19-rc1/2.5.25 provide dummy fsync() routine fordirectories " David Dillow
2002-07-09 19:59               ` [PATCH] 2.4.19-rc1/2.5.25 provide dummy fsync() routine for directories " Alan Cox
2002-07-09 19:59                 ` Alan Cox
2002-07-09 19:50                 ` Richard B. Johnson
2002-07-09 19:50                 ` Richard B. Johnson
2002-07-15  7:52                   ` Sean Hunter
2002-07-15 12:45                     ` Richard B. Johnson
2002-07-15 12:45                     ` Richard B. Johnson
2002-07-15 13:35                       ` Matthias Andree
     [not found]                         ` <mit.lcs.mail.linux-kernel/20020715133507.GF32155@merlin.emma.line.org>
2002-07-15 14:49                           ` Patrick J. LoPresti [this message]
2002-07-15 15:18                             ` Matthias Andree
     [not found]                               ` <mit.lcs.mail.linux-kernel/20020715151833.GA22828@merlin.emma.line.org>
2002-07-15 16:10                                 ` Patrick J. LoPresti
2002-07-15 18:16                                   ` Matthias Andree
     [not found]                                     ` <mit.lcs.mail.linux-kernel/20020715181650.GA20665@merlin.emma.line.org>
2002-07-15 18:56                                       ` Patrick J. LoPresti
2002-07-15 20:50                                         ` Matthias Andree
2002-07-15 16:16                             ` Alan Cox
2002-07-15 15:19                               ` Matthias Andree
2002-07-15 16:45                                 ` Alan Cox
2002-07-15 15:38                               ` Patrick J. LoPresti
2002-07-15 16:55                                 ` Alan Cox
2002-07-15 15:29                                   ` [PATCH] 2.4.19-rc1/2.5.25 provide dummy fsync() routine fordirectories " Sandy Harris
2002-07-15 20:17                                   ` [PATCH] 2.4.19-rc1/2.5.25 provide dummy fsync() routine for directories " Patrick J. LoPresti
2002-07-16  1:40                                     ` jw schultz
2002-07-15 15:20                         ` Bill Rugolsky Jr.
2002-07-15 15:35                           ` Matthias Andree
2002-07-15 16:14                             ` Bill Rugolsky Jr.
2002-07-10  6:33   ` Alex Riesen
2002-07-10 11:20     ` Richard B. Johnson
2002-07-11 10:52 ` Matthias Andree
2002-07-11 11:26   ` Trond Myklebust
  -- strict thread matches above, loose matches on Subject: below --
2002-07-09 13:49 Trond Myklebust
     [not found] <E17SjDh-00067R-00@usw-sf-list2.sourceforge.net>
2002-07-11 19:14 ` Rex Dieter
2002-07-11 20:05   ` Tom McNeal

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=s5gwurxt59x.fsf@egghead.curl.com \
    --to=patl@curl.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthias.andree@stud.uni-dortmund.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.