Talk:Soft updates

This article is rated Stub-class on Wikipedia's content assessment scale.
It is of interest to the following WikiProjects:

Computing

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
???	This article has not yet received a rating on the project's importance scale.
	This article has been automatically rated by a bot or other tool as Stub-class because it uses a stub template. Please ensure the assessment is correct before removing the `\|auto=` parameter.

This is the name as McKusick writes it. I thought the article should be at the right place and fixed all the links to it except someone's user page. - Taxman 22:44, Dec 14, 2004 (UTC)

Are softupdates more flash SSD friendly than journalling? It seems that they should reduce the number of writes (no log) and hence provide a better wear. —Preceding unsigned comment added by Cyril (talk • contribs) 20:40, 27 March 2008 (UTC)[reply]

For FFS-like file systems, yeah, I'd guess so. But overall, FFS and the like aren't very flash friendly, even with softupdates. Even though softupdates will delay and aggregate meta-data updates, the FFS meta-data is still scattered into smaller blocks than optimal for flash. IIUC, a log-structured FS would be way better since flash doesn't have the high seek time of HDDs. Adding some softupdates-like functionality on top of that would be even better (like not simply queueing writes, but only writing the differences needed between the in-core cache and the on-disk flushed state), but probably overkill. Most of the unnecessary writes are prolly restricted to /tmp, and you can deal with that one other ways. —Preceding unsigned comment added by 24.200.77.59 (talk) 21:57, 31 March 2008 (UTC)[reply]