Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Filesystem devs should aim to make “badly written” app code “just work” (2009)

lwn.net

Post reply on HN
Print view View original

101–110 of 117 posts

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#101

Post by zzzcpan »

Animats wrote: post #59

I'd argue that UNIX-type file systems should offer several types of files: * Unit files. When you create a file and write it, it's not visible for other opens until you close it. If you open a file with O_CREAT|O_WRONLY|O_TRUNC, you create a new file, which replaces the old one on close. In the event of a program or system crash, or exiting via "abort" without closing first, the old file remains. So there's always on…

It's not that easy to come up with a decent filesystem API.

Consider that filesystem data cannot be synced to underlying storage in a such way that it can be reliably read later and backups by definition are asynchronous and provide eventual consistency. This means that the best meaningful guarantee an application can get after machine crash is being able to read data written up to some point in the past, but not after every successful fsync before crash. Usually, though, even that guarantee is hard to achieve, as bad blocks happen and redundancy is not there. Given all that it's ok to relax filesystem APIs behavior to proper physical constraints. Like fsync is only meaningful as an ordering operation, no need to actually flush anything to disk immediately on fsync or any operation.

Next is multi process and multi threaded scenarios. Should O_APPEND only work correctly from a single thread, should each write be atomic and to what size, we certainly can't have gigabytes in an atomic append or should there be some synchronization mechanism that blocks others? Same for temporary files and unit files.

And what to do on bad blocks? Should there be redundancy within a single disk, should block device underneath be log structured storage with block remapping and scrubbing and provide reliable storage layer to the outside by sacrificing space? Maybe for desktop machines it should, but not for servers, at least not all of servers, they need a different API.

I'm not even touching performance considerations here, that depend on performance-friendly APIs a lot.

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#102

Post by gpderetta »

dooglius wrote: post #44
peterwwillis wrote: post #25

Earlier quoted context omitted.

I think the difference between "don't implement workarounds" and "use overcommit" is that the kernel can try to be clever, but userland should not have to be clever. The kernel is supposed to just make things work for userland. I think that's why overcommit exists. It's generally not easy to re-design all userland applications to deal with difficult memory management problems in a complex system, but it is easy to ju…

The problem is that userland has to be really clever because of overcommit... that's what the whole thread is about! The reason people want complex things like fsync and barriers is that the OOM killer has normalized the bad idea that applications should behave well when suddenly SIGKILL'd, and this is way harder than looking at the return value from malloc. When a program I write has elevated permissions, which fort…

>bad idea that applications should behave well when suddenly SIGKILL'd,

That's not a bad idea, that's the way that any application that cares about not losing data should behave. OOM is just one of the any reasons an application might suddenly die.

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#103

Post by AnIdiotOnTheNet »

jiggawatts wrote: post #43
bvinc wrote: post #29

I think he's got a point. As a developer I find myself in a different scenario. I'm usually trying to find out what exactly the 100% guaranteed way to do something is. Instead, I find incomplete documentation and different people with different opinions on what the guarantees are, and most people writing bad code that they assume will usually work. Just modifying a file in an atomic way requires a complicated dance o…

I do, but it's not a popular opinion. POSIX, and by extension, the classic 1960s-1980s era UNIX way of doing things just needs die a long overdue death. This stuff was designed at a time when every CPU instruction mattered, everything was optimised to death for frugality, and commands were abbreviated from "copy" to "cp" because ermahgerd two bytes is a huge saving! That mentality got us Y2K. This is an era where lat…

> Every application install should be a union fs. This union fs should be entirely user-mode, so that if an application has 10,000 files, it doesn't take 10,000 round-trips to the OS kernel with the Intel mitigations, context switches, and cache flushes that all brings with it.

I disagree with this, as you've already over-complicated it by assuming some kind of unix-like-scatter-everything-all-over-the-file-tree-for-no-good-reason application installation. Just do what MacOS, RiscOS, DOS, etc did and have applications be a single file (or folder). There, install is just copy, can place it on any media you want, can carry it around with you, keep multiple versions, etc. It even keeps the abstraction of the application actually existing where it appears to exist.

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#104

Post by ken »

zer00eyz wrote: post #5

"Anybody who wants more complex and subtle filesystem interfaces is just crazy. Not only will they never get used, they'll definitely not be stable." I think there is a more universal truism here - that "complex and subtle" are sources of pain, problems and headaches. I want to write "cool" and "magical" code as much as the next person, but that's the stuff that I look at later WTF because I am no longer in the same…

The problem is that everybody agrees on that "universal truism" but nobody can agree on what it means. "Clear, simple, straight forward, plain as day" is up to the reader. They're also a moving target.

To some people, C is simple. To other people, C is full of "complex and subtle" sources of pain.

To some people, a VM with a GC and a JIT is "complex and subtle". To other people, using a HLL with those features enables them to write programs which are much simpler and clearer.

These positions also change over time. A JIT is a fairly standard technique in 2019, but in 1973 it was still very much in the research phase. Even the idea of writing a kernel in such a HLL as C was once revolutionary.

I have an SDET friend who calls these types of universal truisms "apple pie", as in, you hold a meeting and say "Apple pie is good, right?" and everybody nods and says "Yes!" and then goes back to work and absolutely nothing was learned or decided.

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#105

Post by asveikau »

Animats wrote: post #59

I'd argue that UNIX-type file systems should offer several types of files: * Unit files. When you create a file and write it, it's not visible for other opens until you close it. If you open a file with O_CREAT|O_WRONLY|O_TRUNC, you create a new file, which replaces the old one on close. In the event of a program or system crash, or exiting via "abort" without closing first, the old file remains. So there's always on…

> Log files.

I wonder if this would ideally also provide a rotation API. Rotating log files in the presence of multiple writers is messy, and maybe shouldn't be reimplemented at the application layer every time.

> Temporary files

Windows is not always a model of filesystem elegance, but it has a "delete on close" flag in their equivalent to open, which makes it go away on the last close (handle can still be duplicated or inherited, so you get some reference counting through that).

Actually I think you can do similar to this on Unix by unlinking after the open, but keeping an fd open for the lifetime of the temp file.

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#106

Post by tobias3 »

silvestrov wrote: post #86
Animats wrote: post #59

I'd argue that UNIX-type file systems should offer several types of files: * Unit files. When you create a file and write it, it's not visible for other opens until you close it. If you open a file with O_CREAT|O_WRONLY|O_TRUNC, you create a new file, which replaces the old one on close. In the event of a program or system crash, or exiting via "abort" without closing first, the old file remains. So there's always on…

> Unit files. ... you create a new file, which replaces the old one on close. Classic MacOS-9 had the PBExchangeFiles call which did this perfectly. Before call: dirEntryA -> fileContentsA dirEntryB -> fileContentsB after call dirEntryA -> fileContentsB dirEntryB -> fileContentsA This meant that the user kept all meta info for files, e.g. tags, window position, custom icons, etc. So when saving a new document you wro…

Like renameat2 on Linux with RENAME_EXCHANGE ?

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#107

Post by skissane »

TeMPOraL wrote: post #94
skissane wrote: post #73

Earlier quoted context omitted.

> * Temporary files. You can do all the file operations, and the file disappears on a reboot. It would be nice to be able to have a process tree own a temporary file, such that when the last process in the tree exits (not necessarily the process which created the file), the file is automatically deleted, rather than having to wait for the next reboot.

I would prefer it to not be the default; it's sometimes useful to keep temporary files in the event of a process crash, especially on a server that would then immediately restart said process. I had such a case very recently, and was thankful for the existing behavior of tmp files.

Rather than delete the file straight away, put it in a “trash can” or “recycle bin”. A background process deletes files from “trash can” at a later date. It could normally give them a grace period (e.g. 7 days, configurable) but the files could be deleted early if storage space is running low. The same feature could be used to provide undelete for non-temporary files too.

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#108

Post by skissane »

mehrdadn wrote: post #98
Animats wrote: post #59

I'd argue that UNIX-type file systems should offer several types of files: * Unit files. When you create a file and write it, it's not visible for other opens until you close it. If you open a file with O_CREAT|O_WRONLY|O_TRUNC, you create a new file, which replaces the old one on close. In the event of a program or system crash, or exiting via "abort" without closing first, the old file remains. So there's always on…

Fun fact for those who don't know: Windows already has a database API. I've never used it, but it's called the Extensible Storage Engine (JetCreateDatabase, etc.).

Windows also now bundles SQLite [1]. So Windows has more than one “database API”.

[1] C:\windows\system32\winsqlite3.dll

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#109

Post by mehrdadn »

fanf2 wrote: post #100
mehrdadn wrote: post #98

Earlier quoted context omitted.

Fun fact for those who don't know: Windows already has a database API. I've never used it, but it's called the Extensible Storage Engine (JetCreateDatabase, etc.).

Is this the same storage engine that used to provide the back end for Visual Source Safe and Exchange? Which has a 2GB limit per storage unit and corrupts itself irreparably if you hit the limit?

I don't know!

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#110

Post by asveikau »

pas wrote: post #92
jiggawatts wrote: post #43

Earlier quoted context omitted.

I do, but it's not a popular opinion. POSIX, and by extension, the classic 1960s-1980s era UNIX way of doing things just needs die a long overdue death. This stuff was designed at a time when every CPU instruction mattered, everything was optimised to death for frugality, and commands were abbreviated from "copy" to "cp" because ermahgerd two bytes is a huge saving! That mentality got us Y2K. This is an era where lat…

This already exists. O_DIRECT exists, now there's io_urig too (plus the libaio1 which uses io_submit the old async API). The problem is not with files. Kernel transitions are expensive, but the problem is not that. It's metadata sync (file inode + directory inode) and so on. Install is slow on Windows because braindeadness of vendors (cygwin is fast to install). Package stuff is slow on Linux, because apt calls out t…

Windows filesystem performance is also much poorer than Linux for lots of small files.
Post reply on HN