UFS Does UFS in 12.2 have race conditions? They are solved right??

debguy

debguy

I am wondering if UFS v. ZFS I chose UFS - if UFS still has the old race condition.

Long ago BSD and Linux had a race condition: if you read a file before it'd been committed to disk you got the old version of the file (it was called a race condition instead of a bug!). People writing /bin/sh scripts had to be careful of that.

Recently using 12.2 and UFS filesystem I had SEVERAL problems: sometimes I'd save file in vi but file didn't change? I'd recompile check the file and it'd be the same file (without recent changes that 'vi' said were saved). On one file I had changes corrupted (my change, but only 1/2 of the change). I rebooted after seeing that but it still kept happening.

I don't want to throw a red flag because I was in a developer rush and didn't bother to confirm the incidents. But there were several.

I am wondering if UFS v. ZFS I chose UFS - if UFS still has the old race condition, if I should have been expecting (file system corruption).
 
debguy said:
Long ago BSD and Linux had a race condition: if you read a file before it'd been committed to disk you got the old version of the file (it was called a race condition instead of a bug!).
Click to expand...
Not sure what exactly you mean here. POSIX requires that writes to files are atomic, so there's a point in time when you get the (entire) old version, and a (later) point in time when you get the newer version. Also, a read following a write will always get you the new version. Of course, if your read happens in another thread/process than your write, you have a potential race condition, which is entirely YOUR responsibility (and under your control).
debguy said:
Recently using 12.2 and UFS filesystem I had SEVERAL problems: sometimes I'd save file in vi but file didn't change?
Click to expand...
Well, that's a nice story. Sorry, but I don't buy it. Never experienced something like this (and yes, I have one machine using UFS as well).
 
I had 6 tty open and sometimes same Makefile open in two windows. Using elivis in the past never a problem.

Or maybe it was BSD's vi (1)? I'm used to using elvis(1) which never let's me do "w" to save without a warning if it is not going to save. Does BSD's vi have a bug where you are (warned only 1x or never warned) if you file will NOT be saved when doing ":w" ??
 
If you don't know about race conditions you weren't using linux in 1990 were you ? :) Be honest, just because you didn't experience it doesn't mean it wasn't a well known issue everyone knew of in the past.
 
Just to get into more detail for a casual reader: POSIX mandates that ANY read operation that occurs strictly after a completed write operation on the same file will return the new contents. So, this must hold even for scripts launching different processes: if the read occurs AFTER the write, it must give you the new contents.

I won't claim Linux or any BSD was ALWAYS fully compliant here. But even if it wasn't, this issue was limited to (micro?)seconds.

What you describe is something completely different. You're on the wrong track, trust me on this.
 
If it is relevant, vim and vi save in slightly different ways.

When you use :w (n)vi it seems to recreate the file.
When you use :w in vim it appends the existing file.

This has a slight knockon effect (especially using FUSE) if permissions are wrong and you are unable to edit a file you have just created because FUSE mapped it to a different user. (n)vi seems to work because it entirely replaces the file, ignoring the user write permission and succeeding due to group write permission.

Might be the same with what you noticed with Elvis? Either way it suggests your permissions are incorrect.
 
It is interesting this thread is complaining about potential problems with Bill Joy's vi and Bill Joy's BSD. I've never experienced any of the issues spoken of either.

debguy Your Linux roots and background are showing and your behavior and language are very unbecoming and unwelcome in this forum.
 
debguy, you can RTSL of the UFS & VFS and asure yourself that when you save a file, you'll get the saved version on a new read even before the cached buffer pages have been commited to disk. Please do it. OTT, you're free to subscribe to the freebsd-fs mailing list (see Handbook) & talk there seriously. Maybe you have the skills to help with recent bugs, there have been; yes, UFS still has bugs, after this long time. But seriously, not many.
 
I know this bug phenomenon and painfully learnt how to avoid it by making sure I never edit the same file simultaneously in various editors on different consoles.
 
I manage 100+ servers for more than 15 years and the only bug I found related to UFS is with SU enabled:

250576 – PHP-FPM processes hang in UFS-state

bugs.freebsd.org bugs.freebsd.org

I can only trigger it while doing Prestashop translations from the back-end, which during the "Save" it clears Prestashop cache and the filesystem may hang.

I tried to replicate it few months ago with 13-CURRENT without success after:

[base] Revision 367672

svnweb.freebsd.org svnweb.freebsd.org

I will redo the tests after the 13.0-RELEASE.

Another bug but I don't know if it's related to UFS is this:

FreeBSD 13.0-BETA2 and slow IO

lists.freebsd.org

I will try to test it again with 13.0-RC1.
 
debguy said:
if you read a file before it'd been committed to disk you got the old version of the file
Click to expand...
If you read a file before it has been modified, you will get the content before the modification. Absolutely true. Do you expect the file system to have a time machine to know that a modification will happen in the future?

As several other posters have already said: Any file system that claims POSIX conformance will reflect the result of a successful write in reads that occur after the write finishes. That is definitely true for UFS, and I'll bet a case of good wine (which I will give to Kirk McKusick in case I lose the bet, his wine cellar is famously temperature controlled). I know the people who developed the early Linux file systems (such as ext2 and XFS), and I'm very certain that those file systems would also pass this test.

Race conditions in software exist. They do not exist in practice in file systems that most people come in contact with. There is a whole body of theory about what correctness in file systems means, with words like ACID and single-copy serializability.

What you have is a user problem. To begin with, vi probably doesn't even modify files. When it writes a file, it probably creates a new copy in a temporary file, then atomically switches the new copy into the old (yes, there is an atomic rename operation in file systems). If you keep a half dozen vi windows open while also using the files, you likely just confused yourself about which files had been written.

Running around claiming that well-tested file systems (UFS is about 40 years old) still have race conditions bugs in the normal read/write path is insane.
 
You must log in or register to reply here.
Back
Top