Messages in this thread | | | From | John Bradford <> | Subject | Filesystem write priorities, (Was: Re: [RFC] Improved inode number allocation for HTree) | Date | Mon, 10 Mar 2003 21:50:31 +0000 (GMT) |
| |
> |> > Though the journal only becomes involved when blocks are modified, > |> > unfortunately, because of atime updates, this includes all directory > |> > operations. We could suggest to users that they should disable > |> > atime updating if they care about performance, but we ought to be > |> > able to do better than that. > |> > |> On a separate note, since atime updates are not usually very important > |> anyway, why not have an option to cache atime updates for a long time, > |> or until either a write occurs anyway. > > mount -o noatime
Well, yes, I use noatime by default, but I was thinking that there might be users who wanted to gain most of the performance that using noatime would, who still wanted access times available generally, but who were not bothered about loosing them on an unclean shutdown.
Infact, taking this one step further, we could have assign directories priorities, analogous to nice values for processes, and make the lazyness of writes dependant on that.
So, for example, on a webserver, you could assign databases a high priority for writes, but your webserver log a low priority. If the box crashed, the data most likely to be lost would be the webserver log, rather than the database.
Another benefit would be that you could spin down disks, and not have them spin up just to write data to the webserver log - that could be committed to the disk just once an hour, but a database write could cause it to spin up immediately.
John. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |