Hi,
Since non-durable appears to be controversial, let's consider the case
without that aspect.
Since the introduction of ext4, some apps/users have had issues with
file corruption after a system crash. It's not a bug in the FS AFAIK
and it's not exclusive to ext4.
Writing a temp file, fsync, rename is often proposed.
But how does one preserve meta-data, including file owner?
Olaf
On Mon, Dec 27, 2010 at 1:51 PM, Olaf van der Spek <[email protected]> wrote:
> Hi,
>
> Since non-durable appears to be controversial, let's consider the case
> without that aspect.
>
> Since the introduction of ext4, some apps/users have had issues with
> file corruption after a system crash. It's not a bug in the FS AFAIK
> and it's not exclusive to ext4.
> Writing a temp file, fsync, rename is often proposed.
> But how does one preserve meta-data, including file owner?
>
So as I wrote you on the previous thread, in Ext4 you can probably
accomplish that
already by using the Ext4 specific EXT4_IOC_EXT_MOVE ioctl, which is
used by e4defrag
to atomically switch the fragmented copy of the data with a
de-fragmented copy of the data.
It is a more granular version of the exchangedata() BSD API mentioned
in the previous thread:
http://www.manpagez.com/man/2/exchangedata/
So the atomic update is: write(tempfd); fdatasync(tempfd);
exchangedata(tempfd, fd)
If you choose to pursue your campaign for "Atomic file data replace
API", I recommend that you:
1. change the slogan to the more catchy "Implementing exchangedata()
API" (you already have a man page for that)
2. convince VFS people to support the new generic system call /
optional FS operation exchangedata()
3. if you can, post the relevant patches, so people can review and test them
Implementation of exchangedata() operation in Ext4 should be trivial
using the ext4_move_extents() function
and I didn't check, but I bet that XFS has that functionality as well.
Good luck,
Amir.
On Mon, Dec 27, 2010 at 2:20 PM, Amir Goldstein <[email protected]> wrote:
> So as I wrote you on the previous thread, in Ext4 you can probably
FS-specific code should of course be avoided in normal apps.
> It is a more granular version of the exchangedata() BSD API mentioned
> in the previous thread:
> http://www.manpagez.com/man/2/exchangedata/
>
> So the atomic update is: write(tempfd); fdatasync(tempfd);
> exchangedata(tempfd, fd)
Except exchangedata is not (widely) implemented?
Don't you agree it's undesirable to lose meta-data?
Olaf
On Mon, Dec 27, 2010 at 5:53 PM, Olaf van der Spek <[email protected]> wrote:
> On Mon, Dec 27, 2010 at 2:20 PM, Amir Goldstein <[email protected]> wrote:
>> So as I wrote you on the previous thread, in Ext4 you can probably
>
> FS-specific code should of course be avoided in normal apps.
>
>> It is a more granular version of the exchangedata() BSD API mentioned
>> in the previous thread:
>> http://www.manpagez.com/man/2/exchangedata/
>>
>> So the atomic update is: write(tempfd); fdatasync(tempfd);
>> exchangedata(tempfd, fd)
>
> Except exchangedata is not (widely) implemented?
Not in Linux anyway.
> Don't you agree it's undesirable to lose meta-data?
Yes I agree. you can have my vote for "it's nice to have this",
but the fact that we did without it for so long must mean something...
Anyway, you need to convince someone to implement it
(unless you do it yourself), some developers to review it
and the maintainers to accept it, so unless you come up with 'a real
world problem',
the busy FS developers will not be bothered to accept 'the fix'.
Accepting new API's has a huge price of testing them and maintaining them
every release, so don't take the resistance personally.
Now let's say that you decide to focus on the problem of:
'safe editor save to a file which is not owned by you but writable by you'.
You may want to look for a specific editor which has 'safe save' functionality
(maybe LibreOffice?) and query the developers if they would like the new feature
and if they would support your proposal.
That is the way kernel development works - and for good reasons.
Amir.
On Mon, Dec 27, 2010 at 6:20 PM, Amir Goldstein <[email protected]> wrote:
>> Don't you agree it's undesirable to lose meta-data?
>
> Yes I agree. you can have my vote for "it's nice to have this",
> but the fact that we did without it for so long must mean something...
I'm not sure it means something positive.
> Anyway, you need to convince someone to implement it
> (unless you do it yourself), some developers to review it
> and the maintainers to accept it, so unless you come up with 'a real
> world problem',
> the busy FS developers will not be bothered to accept 'the fix'.
> Accepting new API's has a huge price of testing them and maintaining them
> every release, so don't take the resistance personally.
>
> Now let's say that you decide to focus on the problem of:
> 'safe editor save to a file which is not owned by you but writable by you'.
> You may want to look for a specific editor which has 'safe save' functionality
> (maybe LibreOffice?) and query the developers if they would like the new feature
> and if they would support your proposal.
>
> That is the way kernel development works - and for good reasons.
I agree in general you need a good use case. But AFAIK FS devs are
aware of many apps not doing it the right way. So I expected them to
have a FAQ entry that shows what this right way is.
Ted says a huge performance hit is involved, but nobody has been able
to tell why yet.
There's also the problem of not having permission to create a temp file.
Olaf
Olaf
On Mon, Dec 27, 2010 at 12:51:54PM +0100, Olaf van der Spek wrote:
> Since the introduction of ext4, some apps/users have had issues with
> file corruption after a system crash. It's not a bug in the FS AFAIK
> and it's not exclusive to ext4.
> Writing a temp file, fsync, rename is often proposed.
> But how does one preserve meta-data, including file owner?
What's the use case where preserving file ownership matters?
- Ted
On Tue, Dec 28, 2010 at 3:59 AM, Ted Ts'o <[email protected]> wrote:
> On Mon, Dec 27, 2010 at 12:51:54PM +0100, Olaf van der Spek wrote:
>> Since the introduction of ext4, some apps/users have had issues with
>> file corruption after a system crash. It's not a bug in the FS AFAIK
>> and it's not exclusive to ext4.
>> Writing a temp file, fsync, rename is often proposed.
>> But how does one preserve meta-data, including file owner?
>
> What's the use case where preserving file ownership matters?
Why is it you ignore most of the question and only challenge a tiny bit?
I can't think of a problem case right now, but I sure can't guarantee
always resetting file owner is never a problem.
Olaf
On 12/28/2010 12:27 PM, Olaf van der Spek wrote:
> On Tue, Dec 28, 2010 at 3:59 AM, Ted Ts'o<[email protected]> wrote:
>> On Mon, Dec 27, 2010 at 12:51:54PM +0100, Olaf van der Spek wrote:
>>> Since the introduction of ext4, some apps/users have had issues with
>>> file corruption after a system crash. It's not a bug in the FS AFAIK
>>> and it's not exclusive to ext4.
>>> Writing a temp file, fsync, rename is often proposed.
>>> But how does one preserve meta-data, including file owner?
>> What's the use case where preserving file ownership matters?
> Why is it you ignore most of the question and only challenge a tiny bit?
> I can't think of a problem case right now, but I sure can't guarantee
> always resetting file owner is never a problem.
>
> Olaf
I really think that you have missed the point of this list.
This list is for either developers (those who have downloaded the free code and
work on it) or others who want to move things forward concretely.
Perfectly fine to contribute ideas, but if you are not a coder or do not have
the time or inclination to work on things yourself, you have to be *really*
convincing.
We continually get bombarded with ideas, wish list items, etc so we are not
lacking in work to do.
If you cannot explain the use case, you will not get any buy in...
Regards,
Ric
On Tue, Dec 28, 2010 at 8:06 PM, Ric Wheeler <[email protected]> wrote:
> I really think that you have missed the point of this list.
>
> This list is for either developers (those who have downloaded the free code
> and work on it) or others who want to move things forward concretely.
Maybe.
> Perfectly fine to contribute ideas, but if you are not a coder or do not
> have the time or inclination to work on things yourself, you have to be
> *really* convincing.
>
> We continually get bombarded with ideas, wish list items, etc so we are not
> lacking in work to do.
I understand.
> If you cannot explain the use case, you will not get any buy in...
I assumed that preserving file owner would be a normal feature and
would not require additional explanation.
One use case would be updating a file in a save way when you have
write access to that file but not to anything else.
Also, according to Ted, a lot of app devs get saving a file in a safe
way wrong. So I'm asking what the recommended way to do it is. Is that
strange?
Olaf
On 12/28/2010 05:25 PM, Olaf van der Spek wrote:
> On Tue, Dec 28, 2010 at 8:06 PM, Ric Wheeler<[email protected]> wrote:
>> I really think that you have missed the point of this list.
>>
>> This list is for either developers (those who have downloaded the free code
>> and work on it) or others who want to move things forward concretely.
> Maybe.
>
>> Perfectly fine to contribute ideas, but if you are not a coder or do not
>> have the time or inclination to work on things yourself, you have to be
>> *really* convincing.
>>
>> We continually get bombarded with ideas, wish list items, etc so we are not
>> lacking in work to do.
> I understand.
>
>> If you cannot explain the use case, you will not get any buy in...
> I assumed that preserving file owner would be a normal feature and
> would not require additional explanation.
> One use case would be updating a file in a save way when you have
> write access to that file but not to anything else.
>
> Also, according to Ted, a lot of app devs get saving a file in a safe
> way wrong. So I'm asking what the recommended way to do it is. Is that
> strange?
>
> Olaf
I think that various developers have answered this for you several times.
As a suggestion, if you are not a kernel developer, show us specifically a bit
of application code that demonstrates something that you want to have work
differently.
Test it with power failure (buy an external e-sata or USB disk and pull power
while running your app).
Ric
On Tue, Dec 28, 2010 at 11:36 PM, Ric Wheeler <[email protected]> wrote:
> I think that various developers have answered this for you several times.
Not really, unfortunately. Haven't seen a single link to code that
shows how to do it properly.
Temp file, fsync, rename is often mentioned but that skips the
preserving meta-data part and this part, which you also skipped:
One use case would be updating a file in a safe way when you have
write access to that file but not to anything else.
> As a suggestion, if you are not a kernel developer, show us specifically a
> bit of application code that demonstrates something that you want to have
> work differently.
I will.
> Test it with power failure (buy an external e-sata or USB disk and pull
> power while running your app).
The current code?
I think I'll use a VM instead of an external disk. ;)
Olaf
On Wed, Dec 29, 2010 at 12:58 AM, Olaf van der Spek
<[email protected]> wrote:
> On Tue, Dec 28, 2010 at 11:36 PM, Ric Wheeler <[email protected]> wrote:
>> I think that various developers have answered this for you several times.
>
> Not really, unfortunately. Haven't seen a single link to code that
> shows how to do it properly.
> Temp file, fsync, rename is often mentioned but that skips the
> preserving meta-data part and this part, which you also skipped:
> One use case would be updating a file in a safe way when you have
> write access to that file but not to anything else.
>
I think it is safe to say that the *only* option you have now is "temp
file, fsync, rename".
There is no "generic atomic file data replace API in Linux", though it
is available via
private ioctl for XFS and EXT4.
You have started a bit of a storm with your previous thread, which
doesn't help you
much in moving forward in the current thread (previous thread is still
more popular).
I suggest that you humbly swallow you need to know WHY is it hard to implement
non-durable atomic API and focus your attention on the very achievable
data replace API.
IMHO, implementing atomic swap_inodes_data operation shouldn't be difficult
in most file systems (only implementation is simple, but testing and
maintaining
is not to be taken lightly).
Something along the lines of:
1. aquire inodes write/truncate locks
2. start transaction
3. check/update quota limits
4. swap inodes i_data content
5. invalidate (or swap?) inodes page caches
6. mark inodes dirty
7. end transaction & release locks
The real challenge would be to get everyone to agree on a common API
and carve it in stone to the kernel's ABI (is it just swap_inodes_data?
maybe also swap_inode_data_ranges? what about some options?)
Also, as wacky and (some say) faulty the UNIX permissions models is,
current systems have grown old with it, and even 'improving' the behavior
of some applications, may wake up sleeping monsters, so it will not
be done until enough people have pointed out security or usability
issues, which could not be solved otherwise.
In other words, until you find an *application* that wants to allow other
user to modify the content of a file and preserve it's metadata and ownership.
And unless that application cannot find a better way to achieve what it wanted
to do in the first place, or unless that application already has a
large install base
which suffers from *a problem*, you will not have proven *the need*.
Maybe preserving privileged extended attributes is *a need*.
I wouldn't know myself.
Amir.
On Wed, Dec 29, 2010 at 10:20 AM, Amir Goldstein <[email protected]> wrote:
> On Wed, Dec 29, 2010 at 12:58 AM, Olaf van der Spek
> <[email protected]> wrote:
>> On Tue, Dec 28, 2010 at 11:36 PM, Ric Wheeler <[email protected]> wrote:
>>> I think that various developers have answered this for you several times.
>>
>> Not really, unfortunately. Haven't seen a single link to code that
>> shows how to do it properly.
>> Temp file, fsync, rename is often mentioned but that skips the
>> preserving meta-data part and this part, which you also skipped:
>> One use case would be updating a file in a safe way when you have
>> write access to that file but not to anything else.
>>
>
> I think it is safe to say that the *only* option you have now is "temp
> file, fsync, rename".
I'm really looking for a concrete code snippet/function that does this.
For example, file permissions should definitely be preserved.
> There is no "generic atomic file data replace API in Linux", though it
> is available via
> private ioctl for XFS and EXT4.
>
> You have started a bit of a storm with your previous thread, which
> doesn't help you
> much in moving forward in the current thread (previous thread is still
> more popular).
> I suggest that you humbly swallow you need to know WHY is it hard to implement
> non-durable atomic API and focus your attention on the very achievable
> data replace API.
>
> IMHO, implementing atomic swap_inodes_data operation shouldn't be difficult
> in most file systems (only implementation is simple, but testing and
> maintaining
> is not to be taken lightly).
> Something along the lines of:
> 1. aquire inodes write/truncate locks
> 2. start transaction
> 3. check/update quota limits
> 4. swap inodes i_data content
> 5. invalidate (or swap?) inodes page caches
> 6. mark inodes dirty
> 7. end transaction & release locks
>
> The real challenge would be to get everyone to agree on a common API
> and carve it in stone to the kernel's ABI (is it just swap_inodes_data?
> maybe also swap_inode_data_ranges? what about some options?)
Swapping data is an improvement but still not ideal. The API is also
more complex than O_ATOMIC.
> Also, as wacky and (some say) faulty the UNIX permissions models is,
> current systems have grown old with it, and even 'improving' the behavior
> of some applications, may wake up sleeping monsters, so it will not
> be done until enough people have pointed out security or usability
> issues, which could not be solved otherwise.
Each app makes it's own decision about what API to use. Supporting
atomic stuff doesn't change the behaviour of existing apps.
> In other words, until you find an *application* that wants to allow other
> user to modify the content of a file and preserve it's metadata and ownership.
> And unless that application cannot find a better way to achieve what it wanted
> to do in the first place, or unless that application already has a
> large install base
> which suffers from *a problem*, you will not have proven *the need*.
Maybe I should ask devs of some large apps on their take of this issue.
> Maybe preserving privileged extended attributes is *a need*.
> I wouldn't know myself.
Olaf
On the 29.12.2010 13:42, Olaf van der Spek wrote:
> On Wed, Dec 29, 2010 at 10:20 AM, Amir Goldstein<[email protected]> wrote:
>> On Wed, Dec 29, 2010 at 12:58 AM, Olaf van der Spek
>> <[email protected]> wrote:
>>> On Tue, Dec 28, 2010 at 11:36 PM, Ric Wheeler<[email protected]> wrote:
>>>> I think that various developers have answered this for you several times.
>>> Not really, unfortunately. Haven't seen a single link to code that
>>> shows how to do it properly.
No, not this way. You were and still are asked for delivering the code.
Don't pervert the threat of the discussion.
>>> Temp file, fsync, rename is often mentioned but that skips the
>>> preserving meta-data part and this part, which you also skipped:
>>> One use case would be updating a file in a safe way when you have
>>> write access to that file but not to anything else.
>>>
>> I think it is safe to say that the *only* option you have now is "temp
>> file, fsync, rename".
> I'm really looking for a concrete code snippet/function that does this.
> For example, file permissions should definitely be preserved.
>
>> There is no "generic atomic file data replace API in Linux", though it
>> is available via
>> private ioctl for XFS and EXT4.
>>
>> You have started a bit of a storm with your previous thread, which
>> doesn't help you
>> much in moving forward in the current thread (previous thread is still
>> more popular).
>> I suggest that you humbly swallow you need to know WHY is it hard to implement
>> non-durable atomic API and focus your attention on the very achievable
>> data replace API.
>>
>> IMHO, implementing atomic swap_inodes_data operation shouldn't be difficult
>> in most file systems (only implementation is simple, but testing and
>> maintaining
>> is not to be taken lightly).
>> Something along the lines of:
>> 1. aquire inodes write/truncate locks
>> 2. start transaction
>> 3. check/update quota limits
>> 4. swap inodes i_data content
>> 5. invalidate (or swap?) inodes page caches
>> 6. mark inodes dirty
>> 7. end transaction& release locks
>>
>> The real challenge would be to get everyone to agree on a common API
>> and carve it in stone to the kernel's ABI (is it just swap_inodes_data?
>> maybe also swap_inode_data_ranges? what about some options?)
> Swapping data is an improvement but still not ideal. The API is also
> more complex than O_ATOMIC.
>
>> Also, as wacky and (some say) faulty the UNIX permissions models is,
>> current systems have grown old with it, and even 'improving' the behavior
>> of some applications, may wake up sleeping monsters, so it will not
>> be done until enough people have pointed out security or usability
>> issues, which could not be solved otherwise.
> Each app makes it's own decision about what API to use. Supporting
> atomic stuff doesn't change the behaviour of existing apps.
Wrong, we are talking here in the first place about general atomic FS
operations. And to guarantee atomicity you have to change general FS
functions in such a way that in the end all other applications are
affected, or otherwise you have to implement an own (larger part of an) FS.
At this point there is no discussion anymore without code from you,
because this subject is as well discussed to the maximum in information
processing/informatics/computer science.
>> In other words, until you find an *application* that wants to allow other
>> user to modify the content of a file and preserve it's metadata and ownership.
>> And unless that application cannot find a better way to achieve what it wanted
>> to do in the first place, or unless that application already has a
>> large install base
>> which suffers from *a problem*, you will not have proven *the need*.
> Maybe I should ask devs of some large apps on their take of this issue.
Nonsense, because they are already using:
a) the functions available by an FS,
b) the functions available by a DBMS, or
c) a propritary special solution based on the available functions of the
OS and additional functionality that they develope and maintain themselves
for their comparable use cases since decades due to the cost vs. benefit
ratio.
>> Maybe preserving privileged extended attributes is *a need*.
>> I wouldn't know myself.
> Olaf
Christian Stroetmann
On Wed, Dec 29, 2010 at 4:30 PM, Christian Stroetmann
<[email protected]> wrote:
> On the 29.12.2010 13:42, Olaf van der Spek wrote:
>>>> Not really, unfortunately. Haven't seen a single link to code that
>>>> shows how to do it properly.
>
> No, not this way. You were and still are asked for delivering the code.
> Don't pervert the threat of the discussion.
I'm talking about the code for temp file, fsync, rename. Not about
O_ATOMIC code.
>> Each app makes it's own decision about what API to use. Supporting
>> atomic stuff doesn't change the behaviour of existing apps.
>
> Wrong, we are talking here in the first place about general atomic FS
> operations. And to guarantee atomicity you have to change general FS
> functions in such a way that in the end all other applications are affected,
Why's that?
> or otherwise you have to implement an own (larger part of an) FS.
> At this point there is no discussion anymore without code from you, because
> this subject is as well discussed to the maximum in information
> processing/informatics/computer science.
This subject? Exactly what subject?
>> Maybe I should ask devs of some large apps on their take of this issue.
>
> Nonsense, because they are already using:
> a) the functions available by an FS,
Of course. Does that mean the situation can't be improved for them?
> b) the functions available by a DBMS, or
> c) a propritary special solution based on the available functions of the OS
> and additional functionality that they develope and maintain themselves
> for their comparable use cases since decades due to the cost vs. benefit
> ratio.
Olaf
On the 29.12.2010 16:35, Olaf van der Spek wrote:
> On Wed, Dec 29, 2010 at 4:30 PM, Christian Stroetmann
> <[email protected]> wrote:
>> On the 29.12.2010 13:42, Olaf van der Spek wrote:
>>>>> Not really, unfortunately. Haven't seen a single link to code that
>>>>> shows how to do it properly.
>> No, not this way. You were and still are asked for delivering the code.
>> Don't pervert the threat of the discussion.
> I'm talking about the code for temp file, fsync, rename. Not about
> O_ATOMIC code.
Maybe you have not understood the hints: It doesn't matter anymore about
what you are talking unless you present code.
>>> Each app makes it's own decision about what API to use. Supporting
>>> atomic stuff doesn't change the behaviour of existing apps.
>> Wrong, we are talking here in the first place about general atomic FS
>> operations. And to guarantee atomicity you have to change general FS
>> functions in such a way that in the end all other applications are affected,
> Why's that?
read the paragraph as a whole
>> or otherwise you have to implement an own (larger part of an) FS.
>> At this point there is no discussion anymore without code from you, because
>> this subject is as well discussed to the maximum in information
>> processing/informatics/computer science.
> This subject? Exactly what subject?
read the begining of the paragraph
>>> Maybe I should ask devs of some large apps on their take of this issue.
>> Nonsense, because they are already using:
>> a) the functions available by an FS,
> Of course. Does that mean the situation can't be improved for them?
Do you have any code that improves the situation to discuss here?
>> b) the functions available by a DBMS, or
>> c) a propritary special solution based on the available functions of the OS
>> and additional functionality that they develope and maintain themselves
>> for their comparable use cases since decades due to the cost vs. benefit
>> ratio.
> Olaf
Christian Stroetmann
On Wed, Dec 29, 2010 at 5:30 PM, Christian Stroetmann
<[email protected]> wrote:
>> I'm talking about the code for temp file, fsync, rename. Not about
>> O_ATOMIC code.
>
> Maybe you have not understood the hints: It doesn't matter anymore about
> what you are talking unless you present code.
What code?
>>>> Each app makes it's own decision about what API to use. Supporting
>>>> atomic stuff doesn't change the behaviour of existing apps.
>>>
>>> Wrong, we are talking here in the first place about general atomic FS
>>> operations. And to guarantee atomicity you have to change general FS
>>> functions in such a way that in the end all other applications are
>>> affected,
>>
>> Why's that?
>
> read the paragraph as a whole
I have. Still wondering why.
On Wed, Dec 29, 2010 at 10:30 AM, Christian Stroetmann
<[email protected]> wrote:
> On the 29.12.2010 13:42, Olaf van der Spek wrote:
>>
>> On Wed, Dec 29, 2010 at 10:20 AM, Amir Goldstein<[email protected]>
>> ?wrote:
>>>
>>> On Wed, Dec 29, 2010 at 12:58 AM, Olaf van der Spek
>>> <[email protected]> ?wrote:
>>>>
>>>> On Tue, Dec 28, 2010 at 11:36 PM, Ric Wheeler<[email protected]>
>>>> ?wrote:
>>>>>
>>>>> I think that various developers have answered this for you several
>>>>> times.
>>>>
>>>> Not really, unfortunately. Haven't seen a single link to code that
>>>> shows how to do it properly.
>
> No, not this way. You were and still are asked for delivering the code.
> Don't pervert the threat of the discussion.
>
>>>> Temp file, fsync, rename is often mentioned but that skips the
>>>> preserving meta-data part and this part, which you also skipped:
>>>> One use case would be updating a file in a safe way when you have
>>>> write access to that file but not to anything else.
>>>>
>>> I think it is safe to say that the *only* option you have now is "temp
>>> file, fsync, rename".
>>
>> I'm really looking for a concrete code snippet/function that does this.
>> For example, file permissions should definitely be preserved.
>>
>>> There is no "generic atomic file data replace API in Linux", though it
>>> is available via
>>> private ioctl for XFS and EXT4.
>>>
>>> You have started a bit of a storm with your previous thread, which
>>> doesn't help you
>>> much in moving forward in the current thread (previous thread is still
>>> more popular).
>>> I suggest that you humbly swallow you need to know WHY is it hard to
>>> implement
>>> non-durable atomic API and focus your attention on the very achievable
>>> data replace API.
>>>
>>> IMHO, implementing atomic swap_inodes_data operation shouldn't be
>>> difficult
>>> in most file systems (only implementation is simple, but testing and
>>> maintaining
>>> is not to be taken lightly).
>>> Something along the lines of:
>>> 1. aquire inodes write/truncate locks
>>> 2. start transaction
>>> 3. check/update quota limits
>>> 4. swap inodes i_data content
>>> 5. invalidate (or swap?) inodes page caches
>>> 6. mark inodes dirty
>>> 7. end transaction& ?release locks
>>>
>>> The real challenge would be to get everyone to agree on a common API
>>> and carve it in stone to the kernel's ABI (is it just swap_inodes_data?
>>> maybe also swap_inode_data_ranges? what about some options?)
>>
>> Swapping data is an improvement but still not ideal. The API is also
>> more complex than O_ATOMIC.
>>
>>> Also, as wacky and (some say) faulty the UNIX permissions models is,
>>> current systems have grown old with it, and even 'improving' the behavior
>>> of some applications, may wake up sleeping monsters, so it will not
>>> be done until enough people have pointed out security or usability
>>> issues, which could not be solved otherwise.
>>
>> Each app makes it's own decision about what API to use. Supporting
>> atomic stuff doesn't change the behaviour of existing apps.
>
> Wrong, we are talking here in the first place about general atomic FS
> operations. And to guarantee atomicity you have to change general FS
> functions in such a way that in the end all other applications are affected,
> or otherwise you have to implement an own (larger part of an) FS.
> At this point there is no discussion anymore without code from you, because
> this subject is as well discussed to the maximum in information
> processing/informatics/computer science.
>
>>> In other words, until you find an *application* that wants to allow other
>>> user to modify the content of a file and preserve it's metadata and
>>> ownership.
>>> And unless that application cannot find a better way to achieve what it
>>> wanted
>>> to do in the first place, or unless that application already has a
>>> large install base
>>> which suffers from *a problem*, you will not have proven *the need*.
>>
>> Maybe I should ask devs of some large apps on their take of this issue.
>
> Nonsense, because they are already using:
> a) the functions available by an FS,
> b) the functions available by a DBMS, or
> c) a propritary special solution based on the available functions of the OS
> and additional functionality that they develope and maintain themselves
> for their comparable use cases since decades due to the cost vs. benefit
> ratio.
<sarcasm>
Olaf, clearly if you want to find issues / use cases for your new API
you should not talk to developers of complex tools. They have it all
figured out.
It's only you that doesn't know how to code up a userspace solution to
the problem.
<\sarcasm>
Surely productivity suites like openoffice have to address the issue.
How satisfied they are I don't know. And despite Neil's argument that
only one user should be able to write to a given doc, that is just not
how normal office suites work today.
Also, I believe KDE and its myriad of config files has issues with
major config file corruption due to unexpected shutdowns during the
config file update process, so they certainly don't have it figured
out.
Why don't they use the temp file, fsync, rename process?
Those are the 2 user-space suites I would go investigate first. I'm
sure there are many others.
Also, I believe Windows offers an API like your proposing. How does
Samba support it?
Greg
On the 29.12.2010 18:15, Greg Freemyer wrote:
> On Wed, Dec 29, 2010 at 10:30 AM, Christian Stroetmann
> <[email protected]> wrote:
>> On the 29.12.2010 13:42, Olaf van der Spek wrote:
>>> On Wed, Dec 29, 2010 at 10:20 AM, Amir Goldstein<[email protected]>
>>> wrote:
>>>> On Wed, Dec 29, 2010 at 12:58 AM, Olaf van der Spek
>>>> <[email protected]> wrote:
>>>>> On Tue, Dec 28, 2010 at 11:36 PM, Ric Wheeler<[email protected]>
>>>>> wrote:
>>>>>> I think that various developers have answered this for you several
>>>>>> times.
>>>>> Not really, unfortunately. Haven't seen a single link to code that
>>>>> shows how to do it properly.
>> No, not this way. You were and still are asked for delivering the code.
>> Don't pervert the threat of the discussion.
>>
>>>>> Temp file, fsync, rename is often mentioned but that skips the
>>>>> preserving meta-data part and this part, which you also skipped:
>>>>> One use case would be updating a file in a safe way when you have
>>>>> write access to that file but not to anything else.
>>>>>
>>>> I think it is safe to say that the *only* option you have now is "temp
>>>> file, fsync, rename".
>>> I'm really looking for a concrete code snippet/function that does this.
>>> For example, file permissions should definitely be preserved.
>>>
>>>> There is no "generic atomic file data replace API in Linux", though it
>>>> is available via
>>>> private ioctl for XFS and EXT4.
>>>>
>>>> You have started a bit of a storm with your previous thread, which
>>>> doesn't help you
>>>> much in moving forward in the current thread (previous thread is still
>>>> more popular).
>>>> I suggest that you humbly swallow you need to know WHY is it hard to
>>>> implement
>>>> non-durable atomic API and focus your attention on the very achievable
>>>> data replace API.
>>>>
>>>> IMHO, implementing atomic swap_inodes_data operation shouldn't be
>>>> difficult
>>>> in most file systems (only implementation is simple, but testing and
>>>> maintaining
>>>> is not to be taken lightly).
>>>> Something along the lines of:
>>>> 1. aquire inodes write/truncate locks
>>>> 2. start transaction
>>>> 3. check/update quota limits
>>>> 4. swap inodes i_data content
>>>> 5. invalidate (or swap?) inodes page caches
>>>> 6. mark inodes dirty
>>>> 7. end transaction& release locks
>>>>
>>>> The real challenge would be to get everyone to agree on a common API
>>>> and carve it in stone to the kernel's ABI (is it just swap_inodes_data?
>>>> maybe also swap_inode_data_ranges? what about some options?)
>>> Swapping data is an improvement but still not ideal. The API is also
>>> more complex than O_ATOMIC.
>>>
>>>> Also, as wacky and (some say) faulty the UNIX permissions models is,
>>>> current systems have grown old with it, and even 'improving' the behavior
>>>> of some applications, may wake up sleeping monsters, so it will not
>>>> be done until enough people have pointed out security or usability
>>>> issues, which could not be solved otherwise.
>>> Each app makes it's own decision about what API to use. Supporting
>>> atomic stuff doesn't change the behaviour of existing apps.
>> Wrong, we are talking here in the first place about general atomic FS
>> operations. And to guarantee atomicity you have to change general FS
>> functions in such a way that in the end all other applications are affected,
>> or otherwise you have to implement an own (larger part of an) FS.
>> At this point there is no discussion anymore without code from you, because
>> this subject is as well discussed to the maximum in information
>> processing/informatics/computer science.
>>
>>>> In other words, until you find an *application* that wants to allow other
>>>> user to modify the content of a file and preserve it's metadata and
>>>> ownership.
>>>> And unless that application cannot find a better way to achieve what it
>>>> wanted
>>>> to do in the first place, or unless that application already has a
>>>> large install base
>>>> which suffers from *a problem*, you will not have proven *the need*.
>>> Maybe I should ask devs of some large apps on their take of this issue.
>> Nonsense, because they are already using:
>> a) the functions available by an FS,
>> b) the functions available by a DBMS, or
>> c) a propritary special solution based on the available functions of the OS
>> and additional functionality that they develope and maintain themselves
>> for their comparable use cases since decades due to the cost vs. benefit
>> ratio.
> <sarcasm>
> Olaf, clearly if you want to find issues / use cases for your new API
> you should not talk to developers of complex tools. They have it all
> figured out.
>
> It's only you that doesn't know how to code up a userspace solution to
> the problem.
> <\sarcasm>
<no_sarcasm>
This is not the place for sarcasm.
</no_sarcasm>
> Surely productivity suites like openoffice have to address the issue.
> How satisfied they are I don't know. And despite Neil's argument that
> only one user should be able to write to a given doc, that is just not
> how normal office suites work today.
I think that Neil doesn't meant it in this way or context.
> Also, I believe KDE and its myriad of config files has issues with
> major config file corruption due to unexpected shutdowns during the
> config file update process, so they certainly don't have it figured
> out.
>
> Why don't they use the temp file, fsync, rename process?
<no_sarcasm>
Because they figured it out?!
</no_sarcasm>
> Those are the 2 user-space suites I would go investigate first. I'm
> sure there are many others.
>
> Also, I believe Windows offers an API like your proposing. How does
> Samba support it?
>
> Greg
>
<no sarcasm>
Furthermore, in conjunction with the given 2 user-space suites it was said:
"I don't know" and
"I believe".
</no sarcasm>
==> leaving the thread
Please don't TO and CC anymore.
E-mails that are related with this thread will be sorted by name and then deleted without reading on the behalf of the reciever.
Christian Stroetmann