Minimizing JFFS wear with rsync

[Fitz Mutch]

Is it possible to use rsync to reduce JFFS wear, when appending to a large log file on JFFS? How does one measure the # bytes written to the JFFS device (/dev/mtdblock4), for the purpose of seeing how rsync updates the file?

Rsync is famous for its delta-transfer algorithm, which reduces the amount of data sent over the network by sending only the differences between the source files and the existing files in the destination. However, my usage is merely the local filesystem, so I'm only interested in how rsync writes the file.

How does rsync behave when updating a file that has been changed in the middle? I think it would re-write the file from the middle, but this is at least better than re-writing the entire file.

Following is an rsync command, intended to be used when both the source and destination are specified as local paths. I think these rsync options are the best for writing to JFFS, but I need to verify the actual number of bytes written to JFFS.

rsync -axvi --checksum --no-W --no-times --inplace --stats --temp-dir=/tmp --log-file=/tmp/rsync.log /tmp/syslog.log /jffs/

I'm using the Entware-ng version of rsync.

 

[bigeyes0x0]

Considering the P/E cycle on these NANDs are 100k as you can look up on wikidevi and snb reviews by checking their respective model specsheet. You would need to write TBs of data onto these NANDs to fail them. Probably something else will fail first, not something to lose sleep over.