On Thu, 20 Apr 2006, David Tweed wrote: > > What I'm basically checking is that it doesn't, I dunno, rewrite files > so frequently that on a modern flash drive it would wear out the entire > drive unreasonably quickly. The largely write-once nature of git should mean that the only files that get rewritten a lot are - the directories get rewritten to, since git creates new objects at a reasonable pace - the branch references get rewritten. In general, I'd say that git probably does less writing than most other SCM's are likely to do. That said, when you say "modern flash drive", I really suspect you shouldn't care deeply any more. Modern flash devices can be rewritten a lot more than old ones could (by an order of magnitude or more), and they almost always have wear levelling in hw, making it even less of an issue (but if they don't, your biggest issue will be that you should use a filesystem that does it for you). That said, if you want to be safe, I think flash memory card vendors guarantee only up to 10,000 write cycles (and it used to be much less). That's _complete_ rewrites, though, which is more than just a single sector write. They tend to guarantee 100,000 single-sector re-writes (ie more like the "directory update" things when you create a new object). And assuming you'd count one commit as one "total rewrite" (which sounds unlikely - but it's certainly more than one sector - I don't know what they consider a total rewrite when they make up their numbers), that implies that to be really safe, you shouldn't do more than 10,000 commits before you replace your flash. Quite frankly, I suspect that's _way_ more conservative than you should be, but hey, since you asked.. 10,000 commits is actually a fair number. The kernel has gotten 25,000 in a year, but the kernel is a pretty active and large project. I suspect that 10,000 commits is quite a lot of years for most projects. One rule: NEVER mount your flash with the "sync" option, and use "noatime" to avoid unnecessary inode access time updates (that's especially true for git, where archive atimes aren't interesting, but it's usually a good idea for flash in general). Otherwise you'll get normal accesses ending up doign "writes" too and writes will do a lot more of them, and the above "one commit = one rewrite" rule-of-thumb is suddenly not at all conservative. Btw, backups are still good. Flash or no flash, and whether you're very conservative in your flash usage or not. Linus - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html