Scott Laird wrote: > On 10/18/07, Neil Perrin <[EMAIL PROTECTED]> wrote: >> >> Scott Laird wrote: >>> I'm debating using an external intent log on a new box that I'm about >>> to start working on, and I have a few questions. >>> >>> 1. If I use an external log initially and decide that it was a >>> mistake, is there a way to move back to the internal log without >>> rebuilding the entire pool? >> It's not currently possible to remove a separate log. >> This was working once, but was stripped out until the >> more generic zpool remove devices was provided. >> This is bug 6574286: >> >> http://bugs.opensolaris.org/view_bug.do?bug_id=6574286 > > Okay, so hopefully it'll work in a couple quarters?
It's not being worked on currently but hopefully will be fixed in 6 months. > >>> 2. What happens if the logging device fails completely? Does this >>> damage anything else in the pool, other then potentially losing >>> in-flight transactions? >> This should work. It shouldn't even lose the in-flight transactions. >> ZFS reverts to using the main pool if a slog write fails or the >> slog fills up. > > So, the only way to lose transactions would be a crash or power loss, > leaving outstanding transactions in the log, followed by the log > device failing to start up on reboot? I assume that that would that > be handled relatively cleanly (files have out of data data), as > opposed to something nasty like the pool fails to start up. I just checked on the behaviour of this. The log is treated as part of the main pool. If it is not replicated and disappears then the pool can't be opened - just like any unreplicated device in the main pool. If the slog is found but can't be opened or is corrupted then then the pool will be opened but the slog isn't used. This seems a bit inconsistent. > >>> 3. What about corruption in the log? Is it checksummed like the rest of >>> ZFS? >> Yes it's checksummed, but the checksumming is a bit different >> from the pool blocks in the uberblock tree. >> >> See also: >> http://blogs.sun.com/perrin/entry/slog_blog_or_blogging_on > > That started this whole mess :-). I'd like to try out using one of > the Gigabyte SATA ramdisk cards that are discussed in the comments. A while ago there was a comment on this alias that these cards weren't purchasable. Unfortunately, I don't know what is available. > It supposedly has 18 hours of battery life, so a long-term power > outage would kill the log. I could reasonably expect one 18+ hour > power outage over the life of the filesystem. I'm fine with losing > in-flight data (I'd expect the log to be replayed before the UPS shuts > the system down anyway), but I'd rather not lose the whole pool or > something extreme like that. > > I'm willing to trade the chance of some transaction losses during an > exceptional event for more performance, but I'd rather not have to > pull out the backups if I can ever avoid it. > > > Scott _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
