[RFC] Rollback FS

[RFC] Rollback FS

[jiaweiwei]

Hi all,

Recently, I just do some stupid stuffs as follows.

# mv /lib/x86_64-linux-gnu/libc.so.6  /tmp

After move "/lib/x86_64-linux-gnu/libc.so.6" away, you could not run lots
of commands, which show you some errors like this.

# ls
ls: error while loading shared libraries: libc.so.6: cannot open
shared object file: No such file or directory
# mv
mv: error while loading shared libraries: libc.so.6: cannot open
shared object file: No such file or directory
...

Because they all depend on libc.so.

You could also happen to above boring stuffs when you remove some key
files in Linux OS. Now, I have a good idea to solve above problems.

We could implement a File System to record all the operations which
send to VFS. Then when you think you have done a mistake command, you
could rollback from this File System.

This is just a RFC, I would give detail implementations. Would anyone
please give me some suggestions? Thanks very much.

Re: [RFC] Rollback FS

[Richard Weinberger]

On Sun, Oct 20, 2013 at 9:06 AM, jiaweiwei <jiaweiwei.xiyou@gmail.com> wrote:
> Hi all,
>
> Recently, I just do some stupid stuffs as follows.
>
> # mv /lib/x86_64-linux-gnu/libc.so.6  /tmp
>
> After move "/lib/x86_64-linux-gnu/libc.so.6" away, you could not run lots
> of commands, which show you some errors like this.
>
> # ls
> ls: error while loading shared libraries: libc.so.6: cannot open
> shared object file: No such file or directory
> # mv
> mv: error while loading shared libraries: libc.so.6: cannot open
> shared object file: No such file or directory
> ...
>
> Because they all depend on libc.so.
>
> You could also happen to above boring stuffs when you remove some key
> files in Linux OS. Now, I have a good idea to solve above problems.
>
> We could implement a File System to record all the operations which
> send to VFS. Then when you think you have done a mistake command, you
> could rollback from this File System.
>
> This is just a RFC, I would give detail implementations. Would anyone
> please give me some suggestions? Thanks very much.

What about having a good backup and a statically linked busybox somewhere on
your filesystem?

-- 
Thanks,
//richard

Re: [RFC] Rollback FS

[Kristof Provost]

On 2013-10-20 15:06:33 (+0800), jiaweiwei <jiaweiwei.xiyou@gmail.com> wrote:
> We could implement a File System to record all the operations which
> send to VFS. Then when you think you have done a mistake command, you
> could rollback from this File System.
> 
> This is just a RFC, I would give detail implementations. Would anyone
> please give me some suggestions? Thanks very much.

I think it needs to be fleshed out a lot more.

For example, how would you tell it to roll back without a functional
libc? How does it differ from the snapshot feature in btrfs?

Regards,
Kristof

Re: [RFC] Rollback FS

[Vyacheslav Dubeyko]

On Oct 20, 2013, at 11:06 AM, jiaweiwei wrote:

> Hi all,
> 
> Recently, I just do some stupid stuffs as follows.
> 
> # mv /lib/x86_64-linux-gnu/libc.so.6  /tmp
> 
> After move "/lib/x86_64-linux-gnu/libc.so.6" away, you could not run lots
> of commands, which show you some errors like this.
> 
> # ls
> ls: error while loading shared libraries: libc.so.6: cannot open
> shared object file: No such file or directory
> # mv
> mv: error while loading shared libraries: libc.so.6: cannot open
> shared object file: No such file or directory
> ...
> 
> Because they all depend on libc.so.
> 
> You could also happen to above boring stuffs when you remove some key
> files in Linux OS. Now, I have a good idea to solve above problems.
> 
> We could implement a File System to record all the operations which
> send to VFS. Then when you think you have done a mistake command, you
> could rollback from this File System.
> 
> This is just a RFC, I would give detail implementations. Would anyone
> please give me some suggestions? Thanks very much.

Anyway, you need to use Copy-On-Write (COW) approach for such file system.
But there are file systems that implements snapshot approach yet: NILFS2, ext3cow,
Next3, and so on.

Do you really want to implement something likewise snapshot feature in a file system
from the scratch?

With the best regards,
Vyacheslav Dubeyko.

> --
> 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/

Re: [RFC] Rollback FS

[jiaweiwei]

On Sun, Oct 20, 2013 at 3:57 PM, Richard Weinberger
<richard.weinberger@gmail.com> wrote:
> What about having a good backup and a statically linked busybox
> somewhere on your filesystem?
>

I think it should not be a way for a specific file system but a
mechanism like VFS. Anyway, backup would cost a lot. Thanks.



-- 
 do kernel

Re: [RFC] Rollback FS

[jiaweiwei]

On Sun, Oct 20, 2013 at 6:43 PM, Vyacheslav Dubeyko <slava@dubeyko.com> wrote:
> Anyway, you need to use Copy-On-Write (COW) approach for such file system.
> But there are file systems that implements snapshot approach yet: NILFS2, ext3cow,
> Next3, and so on.
>

Any file system should rollback but not specific ones. Therefore, a
VFS like mechanism should be designed and implemented.

> Do you really want to implement something likewise snapshot feature in a file system
> from the scratch?
>

Maybe, I would give detail design, thanks.




-- 
 do kernel

Re: [RFC] Rollback FS

[jiaweiwei]

On Sun, Oct 20, 2013 at 6:22 PM, Kristof Provost <kristof@sigsegv.be> wrote:
> On 2013-10-20 15:06:33 (+0800), jiaweiwei <jiaweiwei.xiyou@gmail.com> wrote:
>> We could implement a File System to record all the operations which
>> send to VFS. Then when you think you have done a mistake command, you
>> could rollback from this File System.
>>
>> This is just a RFC, I would give detail implementations. Would anyone
>> please give me some suggestions? Thanks very much.
>
> I think it needs to be fleshed out a lot more.

Yeah, I think so.

>
> For example, how would you tell it to roll back without a functional
> libc? How does it differ from the snapshot feature in btrfs?

I have not got detail implementation. I would give it and then we
could talk with it.
Thanks.


-- 
 do kernel

Re: [RFC] Rollback FS

[Richard Weinberger]

On Sun, Oct 20, 2013 at 1:37 PM, jiaweiwei <jiaweiwei.xiyou@gmail.com> wrote:
> On Sun, Oct 20, 2013 at 6:43 PM, Vyacheslav Dubeyko <slava@dubeyko.com> wrote:
>> Anyway, you need to use Copy-On-Write (COW) approach for such file system.
>> But there are file systems that implements snapshot approach yet: NILFS2, ext3cow,
>> Next3, and so on.
>>
>
> Any file system should rollback but not specific ones. Therefore, a
> VFS like mechanism should be designed and implemented.

-ENOPATCH

>> Do you really want to implement something likewise snapshot feature in a file system
>> from the scratch?
>>
>
> Maybe, I would give detail design, thanks.

Linux's next generation filesystem, btrfs, has already support for
file and volume level snapshots.

-- 
Thanks,
//richard

Re: [RFC] Rollback FS

[Vyacheslav Dubeyko]

On Oct 20, 2013, at 3:46 PM, Richard Weinberger wrote:

> On Sun, Oct 20, 2013 at 1:37 PM, jiaweiwei <jiaweiwei.xiyou@gmail.com> wrote:
>> On Sun, Oct 20, 2013 at 6:43 PM, Vyacheslav Dubeyko <slava@dubeyko.com> wrote:
>>> Anyway, you need to use Copy-On-Write (COW) approach for such file system.
>>> But there are file systems that implements snapshot approach yet: NILFS2, ext3cow,
>>> Next3, and so on.
>>> 
>> 
>> Any file system should rollback but not specific ones. Therefore, a
>> VFS like mechanism should be designed and implemented.
> 
> -ENOPATCH

Yes, I doubt also that it makes sense to implement such feature on VFS level only.
Anyway, it needs to have support of snapshot feature on concrete file system level.
Otherwise, if it doesn't take into account a concrete file system's internal techniques
then it will have such nonsense as COW under COW. :)

Maybe, VFS needs in transparent rollback support likewise online resize. But such
feature should be based on concrete file systems' internal techniques.

With the best regards,
Vyacheslav Dubeyko.

Re: [RFC] Rollback FS

[Theodore Ts'o]

On Sun, Oct 20, 2013 at 07:37:01PM +0800, jiaweiwei wrote:
> 
> Any file system should rollback but not specific ones. Therefore, a
> VFS like mechanism should be designed and implemented.

And what if the blocks or inodes used for the files that were deleted
have already been used and overwritten?

> Maybe, I would give detail design, thanks.

I encourage you to try to do that; you might find it to be an
educational exercise.

Best regards,

					- Ted

Re: [RFC] Rollback FS

[jiaweiwei]

On Sun, Oct 20, 2013 at 8:35 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Sun, Oct 20, 2013 at 07:37:01PM +0800, jiaweiwei wrote:
>>
>> Any file system should rollback but not specific ones. Therefore, a
>> VFS like mechanism should be designed and implemented.
>
> And what if the blocks or inodes used for the files that were deleted
> have already been used and overwritten?

A good catch. Following ideas would be suitable.

1, Keep the blocks or inodes by a parameter we give.
2, Keep the blocks or inodes for several seconds.

>
>> Maybe, I would give detail design, thanks.
>
> I encourage you to try to do that; you might find it to be an
> educational exercise.
>

Yeah, I would, thanks.


-- 
 do kernel

Re: [RFC] Rollback FS

[Levente Kurusa]

2013-10-20 14:59 keltezéssel, jiaweiwei írta:
> On Sun, Oct 20, 2013 at 8:35 PM, Theodore Ts'o <tytso@mit.edu> wrote:
>> On Sun, Oct 20, 2013 at 07:37:01PM +0800, jiaweiwei wrote:
>>>
>>> Any file system should rollback but not specific ones. Therefore, a
>>> VFS like mechanism should be designed and implemented.
>>
>> And what if the blocks or inodes used for the files that were deleted
>> have already been used and overwritten?
> 
> A good catch. Following ideas would be suitable.
> 
> 1, Keep the blocks or inodes by a parameter we give.
> 2, Keep the blocks or inodes for several seconds.
Keep them where? On the HDD? We just deleted/moved that.
In memory? How about a 4+ GB file(s)?
> 
>>
>>> Maybe, I would give detail design, thanks.
>>
>> I encourage you to try to do that; you might find it to be an
>> educational exercise.
>>
> 
> Yeah, I would, thanks.
> 
> 

I think he meant to be ironic.

-- 
Regards,
Levente Kurusa

Re: [RFC] Rollback FS

[jiaweiwei]

On Sun, Oct 20, 2013 at 9:07 PM, Levente Kurusa <levex@linux.com> wrote:
[...]
>> A good catch. Following ideas would be suitable.
>>
>> 1, Keep the blocks or inodes by a parameter we give.
>> 2, Keep the blocks or inodes for several seconds.
> Keep them where? On the HDD? We just deleted/moved that.

Delete/move a file with a parameter, which would keep the blocks or inodes
in-place. Or we would keep the blocks or inodes for several seconds.




-- 
 do kernel

Re: [RFC] Rollback FS

[Levente Kurusa]

2013-10-20 15:19 keltezéssel, jiaweiwei írta:
> On Sun, Oct 20, 2013 at 9:07 PM, Levente Kurusa <levex@linux.com> wrote:
> [...]
>>> A good catch. Following ideas would be suitable.
>>>
>>> 1, Keep the blocks or inodes by a parameter we give.
>>> 2, Keep the blocks or inodes for several seconds.
>> Keep them where? On the HDD? We just deleted/moved that.
> 
> Delete/move a file with a parameter, which would keep the blocks or inodes
> in-place. Or we would keep the blocks or inodes for several seconds.

The problem with keeping the inodes/blocks for several seconds is
that you would need to find a magic number that is not small enough,
because if it is, then what if the user doesn't notice the problem
during a long operation? If the magic number is big, then we waste a
lot of space.

The problem with the parameter thing is that again, all the different
filesystems need to support that feature. We can't just tell Ext3 or JFFS2 on the VFS level,
that 'Hey, keep those inodes in place incase someone just made himself some headache.'

-- 
Regards,
Levente Kurusa

Re: [RFC] Rollback FS

[jiaweiwei]

On Sun, Oct 20, 2013 at 9:26 PM, Levente Kurusa <levex@linux.com> wrote:
> 2013-10-20 15:19 keltezéssel, jiaweiwei írta:
>> On Sun, Oct 20, 2013 at 9:07 PM, Levente Kurusa <levex@linux.com> wrote:
>> [...]
>>>> A good catch. Following ideas would be suitable.
>>>>
>>>> 1, Keep the blocks or inodes by a parameter we give.
>>>> 2, Keep the blocks or inodes for several seconds.
>>> Keep them where? On the HDD? We just deleted/moved that.
>>
>> Delete/move a file with a parameter, which would keep the blocks or inodes
>> in-place. Or we would keep the blocks or inodes for several seconds.
>
> The problem with keeping the inodes/blocks for several seconds is
> that you would need to find a magic number that is not small enough,
> because if it is, then what if the user doesn't notice the problem
> during a long operation? If the magic number is big, then we waste a
> lot of space.
>
> The problem with the parameter thing is that again, all the different
> filesystems need to support that feature. We can't just tell Ext3 or JFFS2 on the VFS level,
> that 'Hey, keep those inodes in place incase someone just made himself some headache.'
>

Above you said are what we should do. Don't waste time, let me design and
implement it. I would send design document for review, thanks.


-- 
 do kernel

Re: [RFC] Rollback FS

[Levente Kurusa]

2013-10-20 17:22 keltezéssel, jiaweiwei írta:
> On Sun, Oct 20, 2013 at 9:26 PM, Levente Kurusa <levex@linux.com> wrote:
>> 2013-10-20 15:19 keltezéssel, jiaweiwei írta:
>>> On Sun, Oct 20, 2013 at 9:07 PM, Levente Kurusa <levex@linux.com> wrote:
>>> [...]
>>>>> A good catch. Following ideas would be suitable.
>>>>>
>>>>> 1, Keep the blocks or inodes by a parameter we give.
>>>>> 2, Keep the blocks or inodes for several seconds.
>>>> Keep them where? On the HDD? We just deleted/moved that.
>>>
>>> Delete/move a file with a parameter, which would keep the blocks or inodes
>>> in-place. Or we would keep the blocks or inodes for several seconds.
>>
>> The problem with keeping the inodes/blocks for several seconds is
>> that you would need to find a magic number that is not small enough,
>> because if it is, then what if the user doesn't notice the problem
>> during a long operation? If the magic number is big, then we waste a
>> lot of space.
>>
>> The problem with the parameter thing is that again, all the different
>> filesystems need to support that feature. We can't just tell Ext3 or JFFS2 on the VFS level,
>> that 'Hey, keep those inodes in place incase someone just made himself some headache.'
>>
> 
> Above you said are what we should do.
I never said that.
> Don't waste time, let me design and
> implement it. I would send design document for review, thanks.
Do it, but I don't think it would be accepted.


-- 
Regards,
Levente Kurusa

[RFC] Rollback FS

[Nick Warne]

Hi,

> Recently, I just do some stupid stuffs as follows.
>
> # mv /lib/x86_64-linux-gnu/libc.so.6  /tmp
>
> After move "/lib/x86_64-linux-gnu/libc.so.6" away, you could not run lots
> of commands, which show you some errors like this.
>
> # ls
> ls: error while loading shared libraries: libc.so.6: cannot open
> shared object file: No such file or directory
> # mv
> mv: error while loading shared libraries: libc.so.6: cannot open
> shared object file: No such file or directory

Well we all do stupid things sometimes... I done similar to you once, but copied (and overwrote) a different version trying to fix something...

/sbin/sln is your friend (if you don't panic when it happens).  No need for a large vfs to monitor user errors like this.

/sbin/sln is a statically built ln, so you can symlink back the file to get userspace going, then copy the file (fix it) back properly.

Nick
-- 
FSF Associate Member 5508
http://linicks.net/