mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Matthias Andree <matthias.andree@gmx.de>
To: Linux-Kernel mailing list <linux-kernel@vger.kernel.org>
Subject: File system synchronous completion poll.
Date: Fri, 1 Aug 2003 23:23:58 +0200	[thread overview]
Message-ID: <20030801212358.GA18944@merlin.emma.line.org> (raw)

Hi,

it's time again to poll for file system semantics with respect to
synchronous completion, for MTA use.

Define: directory operations := link, rename, mkdir (symlink, rmdir, unlink)

Assume the drive's write cache is off (if your file system is safe with
write cache on, because it queues ordered tags on SCSI, please state
so):

For each of XFS, JFS, ext3fs, ext2fs, reiserfs-3.6, reiserfs-4, for
both of 2.4.21 and 2.6.0-testX, please state (rationale below):

1.  Is mount -o sync implemented?
    If not, does mount -o sync fail?
    If yes, does mount -o sync mean a) "all operations synchronous" or
    b) "directory operations" synchronous?

2.  Is mount -o dirsync implemented?

3.  Is chattr +S implemented, and inherited by freshly-created subdirectories?

4.  Is chattr +D implemented, and inherited by freshly-created subdirectories?

5.  Does
    fd=open("a", ...); rename("a", "b"); fsync(fd); close(fd);
    guarantee that "b" is on disk after fsync() has returned?

6.  Which code fragment makes sure a directory is on disk?
    a. mkdir("parent/sub"); fd=open("parent"); fsync(fd);
    b. mkdir("parent/sub"); fd=open("parent/sub"); fsync(fd);
    This question may not be relevant if the system supports -o sync or
    -o dirsync.

7.  Is rename("a", "b") truly atomic or can it cause a file to either
    end up in lost+found or be there as "a" and "b" in a crash?

The results should be recorded (with date of finding) in man mount(8).

I am aware that XFS, reiserfs and ext3fs as of Linux 2.4 commit all
pending transactions within a file system when an fsync() is requested,
however, this isn't always sufficient (particularly in the mkdir case,
what do you open to fsync it?).

The rationale is to find out how much Linux file systems differ from BSD
UFS + softupdates code, and how well which file system suits the
opposite of the common tuning (data base): mail transfer agent. Their
authors are still reluctant to add explicit fd=open("directory");
fsync(fd) code and assume traditional BSD "noasync" (= dirsync)
semantics.

-- 
Matthias Andree

                 reply	other threads:[~2003-08-01 21:24 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20030801212358.GA18944@merlin.emma.line.org \
    --to=matthias.andree@gmx.de \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®