Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

From learning about how filesystems use transactions and logs to make sure that the disk is in an atomic state even after there's been a system crash, I've become curious about how filesystems deal with concurrency (and I guess this can extend to databases as well).

Basically, what are some key things to keep in mind about concurrent filesystems? Are they what I've currently described them to be?

share|improve this question

closed as not constructive by John Gardeniers, Sven, RobM, Ward, Iain Oct 25 '11 at 14:19

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

How can we possibly know what you currently imagine them to be? While the ability to read minds is a useful skill for sysadmins this might be stretching it a bit far. – John Gardeniers Oct 25 '11 at 6:41
Sorry. What I was wondering was if someone could paint a better picture... – Kaitlyn Mcmordie Oct 25 '11 at 7:10
up vote 0 down vote accepted

First of all, "concurrent filesystem" is not a standard industry term. I'm not sure such a thing exists, unless you're talking about distributed filesystems. So I'll assume you mean instead concurrent file access at the filesystem level.

Filesystems usually deal with concurrency by using locking (i.e. by NOT dealing with concurrency). That is, it's assumed that if I'm writing to a file, then no one else will be writing to the same file at the same time. If you want to forgo locking, then you're presumably accepting the consequences, and presumably dealing with your own concurrency.

Remember that a filesystem really only guarantees the integrity of the filesystem itself, NOT the integrity of your files. If your files get munged, then that's your fault. The FS only says that it won't be the source of your troubles; not that you won't have any of your own fault.

The elements that the filesystem will protect include directory entries, file permissions and metadata, allocation maps, and many such things that you don't care about. And the fact that you don't have to care about them shows that the filesystem is working correctly.

Note that filesystem journals COULD theoretically be used to protect file contents to a certain extent. But the overhead would be unsustainable, and the performance abysmal.

share|improve this answer
Thanks tylerl. Just curious, but what do you mean by "allocation maps"? – Kaitlyn Mcmordie Oct 25 '11 at 15:59
@KaitlynMcmordie Disks have to keep track of which blocks are used and which blocks are free separately from where they track which files are using which blocks. It's a performance thing. If you've got space marked as allocated that doesn't match a file or worse, used space marked as free, then that's a problem. – tylerl Oct 25 '11 at 18:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.