RE: How to restore snaspshot in nilfs?

RE: How to restore snaspshot in nilfs?

[ffffd sssd]

Given several checkpoints, from 1 to 14, and those corresponding to 7, 10, 11 and 14 are snapshots, how can I revert the entire filesystem to the stage 10, for example, discarding all the newer? The only way I've found is to mount the snapshot 10 separately, copy to another disk the contents, format the nilfs and copy back again from the temporal disk to the nilfs...

 		 	   		  --
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to restore snaspshot in nilfs?

[Ryusuke Konishi]

Hi,
On Wed, 27 Jul 2011 23:19:34 +0200, ffffd sssd wrote:
> Given several checkpoints, from 1 to 14, and those corresponding to
> 7, 10, 11 and 14 are snapshots, how can I revert the entire
> filesystem to the stage 10, for example, discarding all the newer?
> The only way I've found is to mount the snapshot 10 separately, copy
> to another disk the contents, format the nilfs and copy back again
> from the temporal disk to the nilfs...

Nilfs does not have a native revert function yet.  So, you need to
synchronize the current mount point with a snapshot as follows:

 # mkdir /nilfs /snap
 # mount -t nilfs2 /dev/xxx /nilfs
 # mount -t nilfs2 -o ro,cp=10 /dev/xxx /snap

 # rsync -axv --delete /snap/ /nilfs/


Regards,
Ryusuke Konishi
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

atime

[David Sariel]

Hi
What was the purpose of reserving the inode for atime file (nilfs2_fs.h)
#define NILFS_ATIME_INO        7    /* Atime file (reserved) */
Correct me if I'm wrong, but it seems to me that updating atime on the disk
result in creating more chekpoints. So spesial file in predetermined 
place can store
atime of all files in the system and spare the need of checkpointings of 
many segments.
Also can you please share your thoughts about the atime implementation 
on nilfs?
Thank you
David



--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: atime

[Ryusuke Konishi]

Hi,
On Mon, 01 Aug 2011 08:53:33 +0300, David Sariel wrote:
> Hi
> What was the purpose of reserving the inode for atime file (nilfs2_fs.h)
> #define NILFS_ATIME_INO        7    /* Atime file (reserved) */

This declaration is reserved for an additional metadata file keeping
atime information on disk.

> Correct me if I'm wrong, but it seems to me that updating atime on the disk
> result in creating more chekpoints. So spesial file in predetermined 
> place can store
> atime of all files in the system and spare the need of checkpointings of 
> many segments.

Yes, if we implement the atime feature and enable it, nilfs will
create checkpoints every time after files are read or directories are
looked up.  It may not be a problem because recent kernels have
``relatime'' which is a nice workaroud of the atime problem.

Anyway, we would turn off this feature by default even if we add it.

> Also can you please share your thoughts about the atime implementation 
> on nilfs?

The atime file would become an array of atime timestamps consisting of
a 64-bit integer number of seconds plus 32 bits of nano-seconds.  The
reason why we reserved a separate metadata file is to minimize the
number of blocks written back by the atime updates.

Or, we may simply add these fields in the extended part of inode; we
have an idea to extend inode size to make other enhancements possible.
Not yet decided, after all.

Regards,
Ryusuke Konishi
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html