On Thu, Apr 26, 2007 at 05:38:07PM -0400, Theodore Tso wrote: > On Fri, Apr 27, 2007 at 06:08:01AM +1000, Nigel Cunningham wrote: > > We tried that. It would need some work. IIRC remounting filesystems > > read-only makes files become marked read-only. Perfectly sensible, > > except that if you then remount the filesystem rw at resume time, all > > those files are still marked ro and userspace crashes and burns. Not > > unfixable, I'll agree, but there is more work to do there. > > There are other solutions, though. One is that we could export a > system call interface which freezes a filesystem and prevents any > further I/O. We mostly have something like that right now (via the > the write_super_lockfs function in the superblock operations > structure), but we haven't exported it to userspace.
It is exported on XFS ;-) > We would also need a similar interface to freeze any block device I/O, > in case you have a database running and doing direct I/O to a block > device. (Or again, we could simply not support that case; how many > people will be running running a database accessing a block deivce on > their laptop?) block device I/O uses generic_file*whateveriscurrenthere*_write, which checks for the freeze flag, so the infrastructure for that is there aswell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
