On 10/18/07, Neil Perrin <[EMAIL PROTECTED]> wrote: > > 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.
Hmm, yeah. What would happen if I mirrored the ramdisk with a hard drive? Would ZFS block until the data's stable on both devices, or would it continue once the write is complete on the ramdisk? Failing that, would replacing the missing log with a blank device let me bring the pool back up, or would it be dead at that point? > >>> 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. The umem one is unavailable, but the Gigabyte model is easy to find. I had Amazon overnight one to me, it's probably sitting at home right now. Scott _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
