NILFS for a "chroot": a kind of a work-around

[Ivan Shmakov <oneingray-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

	It was mentioned recently [1] that NILFS doesn’t handle frequent
	file “creation-removal” cycles well, and these are typical to,
	in particular, # apt-get install (upgrade) operation.

	I’m currently using NILFS for “root” filesystems of a couple of
	chrooted environments I use to test new software, which implies
	that Debian packages are installed and upgraded quite often.

	As a work-around, I’ve made a copy of the filesystem on tmpfs,
	and run # apt-get from there, like:

# chroot /tmp/debian.UvYusUaj apt-get upgrade 

	Then, I propagate the changes back to the original NILFS root
	with rsync(1), like:

# rsync -x -a -v -rlOtH \
      -b --suffix=.~$(date +%s)~ --backup-dir=.rsync-backup \
      --exclude=/.rsync-backup/ --exclude=/.nilfs \
      --delete \
      -- /tmp/debian.UvYusUaj/ /srv/chroot/2012-07-06-unsafe/ 

	This obviously results in much less checkpoints, too, and thus,
	AIUI, less overall stress to the filesystem.

	(Sometimes, I’d also chcp(8) the latest of the newly-made
	checpoints into a snapshot.)

[1] http://permalink.gmane.org/gmane.comp.file-systems.nilfs.user/2397

-- 
FSF associate member #7257	http://sf-day.org/

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