|
|
Subscribe / Log in / New account

XFS: the filesystem of the future?

XFS: the filesystem of the future?

Posted Mar 7, 2012 11:19 UTC (Wed) by dgc (subscriber, #6611)
In reply to: XFS: the filesystem of the future? by dlang
Parent article: XFS: the filesystem of the future?

> the OP is concerned about rather esoteric situations

I know. But what was described was a specific set of block and disk cache manipulations. It wasn't a set of requirements; all I was doing is pointing out if I treated it as a set of requirements then it can be implemented with the existing POSIX API.

> These situations do exist, but they are rather rare and the 'right
> thing' to do is not always and obvious and consistent thing.

And that is precisely why the problem can't be solved by some new magic filesystem operation until the desired behaviour is defined and specified. The weird corner cases that make it hard for userspace also make it just as hard to implement it in the kernel. I see lots of people pointing out why using rename is hard, but their underlying assumption is that moving all this into the kernel will solve all these problems. Well, it doesn't. For example: how does moving the overwrite into the kernel make it any easier to decide whether we should break hard links or not?

IOWs, the issue here is that nobody has defined what the operations being asked for are supposed to do, the use cases, the expected behaviour, constraints, etc.

Before asking kernel developers to do something the problem space needs to be scoped and specified. For the people that want this functionality in the kernel: write a man page for the syscall. Refine it. Implement it as a library function and see if you can use effectively for your use cases. Work out all the kinks in the syscall API. Ask linux-fsdevel for comments and if it can be implemented. Go back to step 1 with all the review comments you receive, then continue looping until there's consensus and somebody implements the syscall with support from a filesystem or two. Once the syscall is done, over time more filesystems will then implement support and then maybe 5 years down the track we can assume this functionality is always available.

But what really needs to happen first is that someone asking for this new kernel functionality steps up and takes responsibility for driving this process.....

Gesta non verba.


to post comments

XFS: the filesystem of the future?

Posted Mar 7, 2012 16:54 UTC (Wed) by XTF (guest, #83255) [Link]

> but their underlying assumption is that moving all this into the kernel will solve all these problems. Well, it doesn't.

Why not? Some of the issues should be easy to avoid in kernel space.

> For example: how does moving the overwrite into the kernel make it any easier to decide whether we should break hard links or not?

What does the non-atomic case do? I'd do the same in the atomic case.

> IOWs, the issue here is that nobody has defined what the operations being asked for are supposed to do, the use cases, the expected behaviour, constraints, etc.

My request was quite clear: Could any of the fsync advocates post real code that does the atomic variant of open, write, close?
Isn't that quite well-defined?

> Before asking kernel developers to do something the problem space needs to be scoped and specified

Before that, we should agree that these are valid issues / assumptions / regressions.

> But what really needs to happen first is that someone asking for this new kernel functionality steps up and takes responsibility for driving this process.....

That'd be great, but at the moment most (FS) devs (and others) just declare these non-issues and refuse to discuss.


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