On Mon, Dec 22, 2003 at 07:07:27PM +0100, Christophe Saout wrote: > Hi Joe, > > > #if 0 > > /* FIXME: not convinced by this */ > > if (current->flags & PF_FREEZE) > > refrigerator(PF_IOTHREAD); > > #endif > > I've got a notebook some time ago and just checked: > > Without this refrigerator thing suspend to ram fails: k, I'll put it back in, thanks for testing. > BTW, I'm using the snapshot code in 2.6 on a production system for some > time now (backups using rsync every night) and it's working great. Good. > I > don't think I'm running into corner cases too much though. I know that > without the vfs locking it's not too reliable but I'm running sync > before creating the snapshots and there's nobody on the machine in the > night so it's ok for me. Since the snapshots are writeable the fs > journal can be replayed on mounting. > > When do you think some of the code is ready? Kevin Corry and I have a few changes that we've got queued up. We're going to write up a todo list and make it publically available so people can track progress. > Another thing: There still seems to be trouble with the loop driver, the > block device backend support seems to be broken. There are some patches > but they in turn seem to introduce other problems... I've still my > dm-crypt target floating around. With it there would be a working > alternative. What did Andrew tell you when you asked him? I talked with > one of the people that are working on the cryptoloop support and he > agreed that device-mapper would be a better place for this. I'm happy to take the dm-crypt stuff into my unstable tree. I don't think you'll get it into the kernel unless you get the cryptoloop people to publically (ie. on lkml) support you. Did you come to any conclusion about the comments that your target wasn't shuffling blocks ? - Joe