Ryusuke Konishi wrote:
>
>> I converted (backup/restore) my home directory onto nilfs2 to test it in
>> anger (yes i know the caveats about it corrupting all my data, etc, but
>> i'm willing to restore when required).
>
> What happened to you ?
> Anyway, thanks for your interest in nilfs.
> (yeah, I'm trying my best, but I keenly feel it's really tough to keep
> the reliability of the filesystem. so, please remember the caveat.)
Yes, understood very well, but you also you underestimate your code ;-)
Please keep up the good work. The free world has been waiting for this
kind of filesystem for a while.
>> So is there a way to temporarily suspend checkpointing with a
>> command and then restart it after the restore has completed ? I
>> think this would be useful also for when you want to have a
>> 'privacy' mode (like firefox/mozilla) where you can suspend
>> checkpointing, start some confidential work, email, browsing etc,
>> and then restart checkpointing and roll back to the previous state.
>
> Is your demand rollback feature or some kind of silent (or invalid by
> default) checkpointing, or both ?
No, not demanding anything. Requesting it as a feature. While your
design has a very crucial use-case of constant checkpointing, there is
also a use-case to *suspend* checkpointing (or enable it on demand
only). As mentioned in my previous example, when restoring to a
filesystem, or even installing new software, it is extremely unlikely
that you would want a to go back to a point *inbetween* the time you
started the install/restore to the time it completed. Say for example
you are installing a new version of Openoffice which installs
home:/opt/openoffice.org$ find . ! -type d |wc -l
4100
4000 odd files. For sure if the software didn't work, crashed, was
buggy, i would go back completely to the pre-install state and would
never need any intervening checkpoint. In this case i would suspend
checkpointing before installing (which may by default create a
snapshot), and then i'd restart the constant checkpointing after i'd
finished the install/restore. Please note, i am not comparing nilfs to
zfs, but zfs doesn't have constant cp (i think) but does have the
feature i mention, i.e you take snapshots when needed (perhaps via a
cron job daily, monthly, weekly)
> The checkpointing is essential for nilfs, every write on nilfs
> requires creating a checkpoint by its nature. But I think it's
> possible to make them inaccessible by default.
>
> Rollback is worth considering. Yes, I agree. it actually makes the
> recovery of filesystem state smarter.
>
> It even could be a first step toward realization of the remote
> replication (as discussed before in this mailing list).
Yes, after i posted, i went back on the mailing list and seen the
request already. Sorry for requesting the feature again.
> I think it needs care because the feature partially invalidate what
> the nilfs stands for. Maybe 5 seconds checkpoining should be remained
> as default. But some flexiblity might well be allowed as you pointed
> out.
Agreed, but it wouldn't invalidate what nilfs stood for, it would
enhance it, but it is your code, so it's your right to decide and i
respect that.
> Supporting method changing cleaning interval without editing the conf
> file, sounds reasonable (yes, sorry for inconvenience).
No need to apologize.
>> Finally instead of having 5 commands, it'd be nice to have once command
>> with different options (like zfs). So instead have
>>
>> . nilfs checkpoint
>> . nilfs snapshot
>> . nilfs remove
>> . nilfs list
>> . nilfs suspend
>> . nilfs restart
>> etc...
>
> Yeah, I agree reorganizing commands into one 'nilfs' command is
> preferable. Well, I'll add this to the todo items on the site.
Thanks (my /usr/bin directory seems to be growing exponentially).
> I think it would be nice if the old commands are available through
> symbolic links to this unified command according to user's
> predilection.
Agreed, but why have 5 commands and 5 manpages when you can have 1 of
each ;-). I think users will get used to it and eventually you can
delete the symlinks.
Thanks for your responses.
D
_______________________________________________
users mailing list
[email protected]
https://www.nilfs.org/mailman/listinfo/users
