User: Password:
|
|
Subscribe / Log in / New account

XFS: the filesystem of the future?

XFS: the filesystem of the future?

Posted Mar 5, 2012 22:55 UTC (Mon) by nybble41 (subscriber, #55106)
In reply to: XFS: the filesystem of the future? by XTF
Parent article: XFS: the filesystem of the future?

>> The only part that really needs to be atomic is the metadata update. That's not usually a problem so long as your on-disk inodes, or at least those fields relating to top-level data block allocation, fit within one physical sector:

> They don't and that's not how atomicity is guaranteed. Atomicity is guaranteed via the journal.

I can only assume you have a particular filesystem in mind. It is possible to arrange for inodes (or at least the data block portions) to fit within one sector, and to have atomic metadata updates without a journal. If you have a journal, great; atomic updates shouldn't be a problem. However, this system can also be retrofitted onto filesystem which do not support journals.

>> This does assume _complete_ replacement, i.e. O_ATOMIC implies O_TRUNC.

> Not really, actually. You merely have to ensure that the old state / blocks remain valid, so you have to do all writes to new blocks.

True, if you want to implement full copy-on-write semantics. I was going for a simpler approach which can be implemented by almost any filesystem with no on-disk structure changes.


(Log in to post comments)

XFS: the filesystem of the future?

Posted Mar 6, 2012 0:10 UTC (Tue) by XTF (guest, #83255) [Link]

> I can only assume you have a particular filesystem in mind

Not really

> True, if you want to implement full copy-on-write semantics. I was going for a simpler approach which can be implemented by almost any filesystem with no on-disk structure changes.

What do you mean by full copy-on-write semantics?
What on-disk structure changes would be required to do this in ext4 for example?

XFS: the filesystem of the future?

Posted Mar 6, 2012 0:49 UTC (Tue) by nybble41 (subscriber, #55106) [Link]

>> I can only assume you have a particular filesystem in mind
> Not really

In that case, why did you say that on-disk inodes do not fit within one physical sector? That is filesystem-specific, and I certainly know of some where the full inode size is less than or equal to 512 bytes; ext2 is at least capable of being configured that way.

>> True, if you want to implement full copy-on-write semantics. I was going for a simpler approach which can be implemented by almost any filesystem with no on-disk structure changes.
> What do you mean by full copy-on-write semantics?
> What on-disk structure changes would be required to do this in ext4 for example?

Perhaps none. I didn't mean to imply that it was impossible to implement atomic replacement of partial files without changing the on-disk structure; I simply hadn't proved to myself that it could be done easily. In retrospect it probably could be done, though you would run into the aforementioned fragmentation issues common to most C.O.W. filesystems.

The biggest complication is not on disk but in memory; you would need to modify the filesystem code to account for the shared data blocks, of which there may be as many alternate versions as there are O_ATOMIC file descriptors--unless O_ATOMIC is exclusive, of course.

XFS: the filesystem of the future?

Posted Mar 6, 2012 12:55 UTC (Tue) by XTF (guest, #83255) [Link]

> In that case, why did you say that on-disk inodes do not fit within one physical sector?

You're right, inodes typically do fit in a sector.
What I wanted to say is that a meta-data transaction usually involves multiple parts / sectors. Providing consistency guarantees after a crash is hard without a journal.

> unless O_ATOMIC is exclusive, of course.

Having a reader and a writer or multiple writers at the same time is always problematic.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds