Good morning Josh, Good morning all,

We use to force a YAFFS2 checkpoint (in a Linux root filesystem) after a modification and when we're not going to change it anymore for some time.
For that we're remounting the partition in read only (it's a fake "remount" in "read-only", i.e. we could still write in the file system, but it just forces the check point).

I'm copying you two bits of codes in case that might help:

1) we added yaffs_remount_fs in the struct super_operations:

	static struct super_operations yaffs_super_ops = {
	        .statfs = yaffs_statfs,
	
	        .put_inode = yaffs_put_inode,
	        .put_super = yaffs_put_super,
	        .remount_fs = yaffs_remount_fs,
	        .delete_inode = yaffs_delete_inode,
	        .clear_inode = yaffs_clear_inode,
	        .sync_fs = yaffs_sync_fs,
	        .write_super = yaffs_write_super,
	};

2) we implemented the function  yaffs_remount_fs this way:

static int yaffs_remount_fs(struct super_block *sb, int *flags, char *data)
	{
	        yaffs_Device    *dev = yaffs_SuperToDevice(sb);
	
	        if( *flags & MS_RDONLY ) {
	                struct mtd_info *mtd = yaffs_SuperToDevice(sb)->genericDevice;
	
	                T(YAFFS_TRACE_OS,
	                        (KERN_DEBUG "yaffs_remount_fs: %s: RO\n", dev->name ));
	
	
	        if (current != dev->readdirProcess)
	            yaffs_GrossLock(dev);
	
	                yaffs_FlushEntireDeviceCache(dev);
	
	        yaffs_CheckpointSave(dev);
	
	                if (mtd->sync)
	                        mtd->sync(mtd);
	
	        if (current != dev->readdirProcess)
	            yaffs_GrossUnlock(dev);
	        }
	        else {
	                T(YAFFS_TRACE_OS,
	                        (KERN_DEBUG "yaffs_remount_fs: %s: RW\n", dev->name ));
	        }
	
	        return 0;
	}

These examples are an excerpt from what's running on our embedded software with kernel 2.6.25 ... I will be out of office for a few days, but after that, I can come back with a better defined patch in case you might be interested and if these bits of code are not enough .

Regards,

Jean-Loup Sabatier

________________________________________
From: yaffs-bounces@lists.aleph1.co.uk [yaffs-bounces@lists.aleph1.co.uk] On Behalf Of Josh Gelinske [jgelinske@appareo.com]
Sent: Wednesday, March 31, 2010 3:00 PM
To: yaffs@lists.aleph1.co.uk
Subject: [Yaffs] Periodic Checkpointing

I have two large (4GB) NANDs in my system and I want to try implementing a periodic checkpoint mechanism to help speed up boot. Given the heavy amount of IO and the amount of state the checkpoint snapshots for these NANDS I cannot guarantee I can get a clean unmount (more like I can guarantee I will get an unclean shutdown).

My current thought is to add a kernel thread that will checkpoint every 30 seconds to 1 minute. Each time I “auto” checkpoint I would remove the older checkpoint once the new one is written. Of course given the timeing of shutdown can’t be guaranteed this means I need to handle cleaning up that old checkpoint a boot as well in case it did not get erased. I have this much working and it improves boot time but of course there are issues.

 The part I am missing and am unsure the best way to implement is the scan that I need to do for any changes after my checkpoint. Currently any modifications after my auto checkpoint are lost and this can cause corruption of existing data etc. Any ideas on the best way to do this? Am I completely going down the wrong path here?

Regards,

JG



JOSH GELINSKE
FIRMWARE ENGINEERING MANAGER

Appareo Systems, LLC
1810 NDSU Research Circle N
Fargo, ND 58102
P: (701) 356-2200 Ext 251
F: (701) 356-3157
http://www.appareo.com
mailto:jgelinske@appareo.com

{*}

NOTICE: This message (including attachments) is covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 2510-2521, is CONFIDENTIAL and may also be protected by ATTORNEY-CLIENT OR OTHER PRIVILEGE. If you believe that it has been sent to you in error, do not read it. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error and then delete it.


{-}