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.
On Sun, Oct 20, 2013 at 9:06 AM, jiaweiwei <[email protected]> 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
On 2013-10-20 15:06:33 (+0800), jiaweiwei <[email protected]> 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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Sun, Oct 20, 2013 at 3:57 PM, Richard Weinberger
<[email protected]> 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
On Sun, Oct 20, 2013 at 6:43 PM, Vyacheslav Dubeyko <[email protected]> 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
On Sun, Oct 20, 2013 at 6:22 PM, Kristof Provost <[email protected]> wrote:
> On 2013-10-20 15:06:33 (+0800), jiaweiwei <[email protected]> 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
On Sun, Oct 20, 2013 at 1:37 PM, jiaweiwei <[email protected]> wrote:
> On Sun, Oct 20, 2013 at 6:43 PM, Vyacheslav Dubeyko <[email protected]> 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
On Oct 20, 2013, at 3:46 PM, Richard Weinberger wrote:
> On Sun, Oct 20, 2013 at 1:37 PM, jiaweiwei <[email protected]> wrote:
>> On Sun, Oct 20, 2013 at 6:43 PM, Vyacheslav Dubeyko <[email protected]> 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.
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
On Sun, Oct 20, 2013 at 8:35 PM, Theodore Ts'o <[email protected]> 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
2013-10-20 14:59 keltez?ssel, jiaweiwei ?rta:
> On Sun, Oct 20, 2013 at 8:35 PM, Theodore Ts'o <[email protected]> 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
On Sun, Oct 20, 2013 at 9:07 PM, Levente Kurusa <[email protected]> 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
2013-10-20 15:19 keltez?ssel, jiaweiwei ?rta:
> On Sun, Oct 20, 2013 at 9:07 PM, Levente Kurusa <[email protected]> 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
On Sun, Oct 20, 2013 at 9:26 PM, Levente Kurusa <[email protected]> wrote:
> 2013-10-20 15:19 keltez?ssel, jiaweiwei ?rta:
>> On Sun, Oct 20, 2013 at 9:07 PM, Levente Kurusa <[email protected]> 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
2013-10-20 17:22 keltez?ssel, jiaweiwei ?rta:
> On Sun, Oct 20, 2013 at 9:26 PM, Levente Kurusa <[email protected]> wrote:
>> 2013-10-20 15:19 keltez?ssel, jiaweiwei ?rta:
>>> On Sun, Oct 20, 2013 at 9:07 PM, Levente Kurusa <[email protected]> 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