> Yes, I think we've all agreed we can do it ... it's now a question of > whether we can stomach the ick factor of actually initiating a > transaction in close ... I'm still feeling queasy. NFS does transactions - including figuring out if the data will fit - on file close. It does that for real data so I'd relax. With hard disks we don't even complete a set of actions on close they just float around for a bit and get committed (but if there is a media failure you lose if you didnt commit them first via fsync etc) > The alternative might be a two file approach (either in sysfs or a mini > custom fs), one for load up data and the other for initiate transaction > with the data errors (like overflow) being returned on the load up file > and the transaction errors being returned on the write that initiates > the transaction. The two file problem then turns into the "which transaction of the two done in parallel" problem. > My architectural sense is that transaction on close, provided we can > make it a more universally accepted idea, has a lot of potential because > it's more intuitive than the two file approach. Agreed Alan -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
