On Wed, 9 Jul 2008 17:13:46 +1000 Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > one can argue about the need of doing the first 3 steps via a > > userland loop; it sure sounds like one needs to be really careful > > to not do any writes to the fs from the app that does snapshots > > (and that includes doing any syscalls in the kernel that allocate > > memory.. just because that already could cause unrelated data to be > > written from inside the app. Not fun.) > > Bloody hell! Doesn't *anyone* understand that a frozen filesystem is > *clean*? That the process of freezing it ensures all dirty data and > metadata is written out before the freeze completes? And that once > frozen, it can't be dirtied until unfrozen? > > That's 3 (or is it 4 - maybe 5 now that I think about it) different > ppl in 24 hours that have made this same broken argument about > being unable to write back dirty data on a frozen filesystem...... unless you also freeze the system as a whole (in a 'refrigerator suspend' way).. the "clean" part is just about a nanosecond long. After that stuff gets dirty again (you're doing that sendfile to receive more packets from the FTP upload etc etc). Sure you can pause those. But there's a real risk that you end up pausing the app that you want to unfreeze the fs (via the memory allocation->direct reclaim path). And no, mlock doesn't help. Especially with delayed allocation, where data writes will cause metadata activity, this is not just theory. -- If you want to reach me at my work email, use arjan@xxxxxxxxxxxxxxx For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
