linux-ext4 - [Bug 15910] zero-length files and performance degradation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201005102233.o4AMXFav021768@demeter.kernel.org>
Date:	Mon, 10 May 2010 22:33:15 GMT
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 15910] zero-length files and performance degradation

https://bugzilla.kernel.org/show_bug.cgi?id=15910

--- Comment #9 from Theodore Tso <tytso@....edu>  2010-05-10 22:33:09 ---
I'll grant that using sync(2) is non-portable, but relying on _not_ needing an
fsync(2) at all was also just as non-portable, if not worse (it only really
worked on ext3, and no other file system, and of course only on Linux).

Trying to make (fsync ,rename)**N --- that is, alternating fsync and rename
calls --- fast is always going to be difficult for nearly all file systems. 
The fundamental problem is that file systems are optimized for throughput when
you're _not_ calling fsync all the time, that's a very different sort of thing
than what databases need to do --- and databases generally solve the problem by
having _two_ logs, a redo and an undo log.  I don't know of any filesystem
which has that kind of complexity, and so pretty much any filesystem where you
have a series if fsync() and rename() calls interleaves is going to run you
into pain.   Some filesystems will be better at it than others, but it's always
going to be faster to write all the files, do a single sync, and then do all of
the renames.   Yeah, that's non-portable; the problem is that the only
synchronization primitive which POSIX gives us is fsync(), and so we just don't
have a lot of options in terms of what we communicate between userspace and the
kernel.

One of the things I wonder about is why are users' systems cashing so often
such that this is a problem?  I can't remember the last time I've had a system
crash while I've been doing an "apt-get dist-upgrade" or "apt-get upgrade".  Is
this a common problem or an uncommon problem?    And if it's not that common
(and I hope it is, but maybe Ubuntu is shipping too many unstable crappy binary
device drivers), maybe the right answer is to have rescue CD's or rescue
partitions which will automatically repair a damaged libc package if the
systems just happened to crash while upgrading glibc.   Again, let's optimize
for the common case, and I hope we've haven't entered the windows world where
blue screens of death are so common that this is the case we have to optimize
for....

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html