On Sat, 8 Dec 2012 12:20:29 +1100 Dave Chinner <david@xxxxxxxxxxxxx> wrote: First off, thanks for the examples. I'll answer your one question and then I'll shut up! > > I'll try and chase this up by submitting patches to lvcreate and > > fsfreeze (in the former case, I think there's no reason not to run > > syncfs; in the latter perhaps it should be a command line option). > > Is that even necesary? users can issue the sync themselves if > necessary.... I think it's necessary for the issue to be better documented in LVM at the very least. I've dabbled with LVM for nearly 10 years, and used it in a busy production environment for around 6. For nearly 2 years I've been seeing, every now and then, these odd cases where taking a snapshot caused irrecoverable high load on the server. I've never seen any mention anywhere of the advisability of manually running sync prior to taking a snapshot on a busy system, and I had to get down to looking at the kernel sources before I got an inkling this might be the issue. I'd imagine that the vast majority of end users think the same way as I did, viz that taking a snapshot was designed to have minimal effect on any other users of the filesystem. There's also the issue that AFAIK there's no commonly distributed program which will allow you to call syncfs() on a filesystem. Running sync is a bit of a sledgehammer approach for a busy system with multiple large filesystems. I've submitted a patch to util-linux, adding a --sync option to fsfreeze which, if specified, will syncfs the requested filesystem prior to any freeze operation. Hopefully they'll accept this, though the only comment I've received so far suggested that I should be submitting a kernel patch rather than band aiding it in userland! Looking at the LVM sources, it would appear that the freezing of affected filesystems is done in the kernel side of device mapper. I'm not going there! Anyway, thanks for your time. Cheers, Alun. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html