×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Comments

top

Is ext4 Stable For Production Systems?

doug363 Re:Wrong question (289 comments)

Hear, hear. That's exactly the problem. The invariant of rename is useful, and it is useful to be able to get the atomic cutover without ensuring that the file is on disk. The previous ext4 behaviour is utterly useless to everyone. The reason is that there is an important case that hasn't been raised much: where the process doing the renaming isn't the process doing the writing. Consider:

$ echo "Hello, world" > file.new # or some other operation that produces file.new
$ mv file.new file
$ [System crashes some time after mv completes.]

In this case, the shell probably doesn't do an fsync before it closes file.new, so the bug might appear. Basically, the implication of not solving this is the kernel is that every application that writes a file needs to be changed to fsync before closing it, if someone else might later want to rename it over another file. That is equivalent to an enforced fsync_on_close flag, but also requires that every application is changed, and it completely wipes out the lazy allocation, write-behind optimisation that this was all supposed to allow. The only realistic possibility is for mv to open file.new and fsync it before renaming, but that's racy, so the kernel is the only place where this problem can be fixed properly.

more than 5 years ago
top

Visual Basic on GNU/Linux

doug363 Re:OS X Intel? (383 comments)

Were you looking for the IsNot patent? It was covered on /. a couple of years ago. The patent specifically refers to Visual Basic .NET.

more than 6 years ago

Submissions

doug363 hasn't submitted any stories.

Journals

doug363 has no journal entries.

Slashdot Login

Need an Account?

Forgot your password?