Everyone, Thanks for the help. I really appreciate it.
Well, I actually walked through the source code with an associate today and we found out how things work by looking at the code. It appears that L2ARC is just assigned in round-robin fashion. If a device goes offline, then it goes to the next and marks that one as offline. The failure to retrieve the requested object is treated like a cache miss and everything goes along its merry way, as far as we can tell. I would have hoped it to be different in some way. Like if the L2ARC was striped for performance reasons, that would be really cool and using that device as an extension of the VM model it is modeled after. Which would mean using the L2ARC as an extension of the virtual address space and striping it to make it more efficient. Way cool. If it took out the bad device and reconfigured the stripe device, that would be even way cooler. Replacing it with a hot spare more cool too. However, it appears from the source code that the L2ARC is just a (sort of) jumbled collection of ZFS objects. Yes, it gives you better performance if you have it, but it doesn't really use it in a way you might expect something as cool as ZFS does. I understand why it is read only, and it invalidates it's cache when a write occurs, to be expected for any object written. If an object is not there because of a failure or because it has been removed from the cache, it is treated as a cache miss, all well and good - go fetch from the pool. I also understand why the ZIL is important and that it should be mirrored if it is to be on a separate device. Though I'm wondering how it is handled internally when there is a failure of one of it's default devices, but then again, it's on a regular pool and should be redundant enough, only just some degradation in speed. Breaking these devices out from their default locations is great for performance, and I understand. I just wish the knowledge of how they work and their internal mechanisms were not so much of a black box. Maybe that is due to the speed at which ZFS is progressing and the features it adds with each subsequent release. Overall, I am very impressed with ZFS, its flexibility and even more so, it's breaking all the rules about how storage should be managed and I really like it. I have yet to see anything to come close in its approach to disk data management. Let's just hope it keeps moving forward, it is truly a unique way to view disk storage. Anyway, sorry for the ramble, but to everyone, thanks again for the answers. Mike --- Michael Sullivan michael.p.sulli...@me.com http://www.kamiogi.net/ Japan Mobile: +81-80-3202-2599 US Phone: +1-561-283-2034 On 7 May 2010, at 00:00 , Robert Milkowski wrote: > On 06/05/2010 15:31, Tomas Ögren wrote: >> On 06 May, 2010 - Bob Friesenhahn sent me these 0,6K bytes: >> >> >>> On Wed, 5 May 2010, Edward Ned Harvey wrote: >>> >>>> In the L2ARC (cache) there is no ability to mirror, because cache device >>>> removal has always been supported. You can't mirror a cache device, >>>> because >>>> you don't need it. >>>> >>> How do you know that I don't need it? The ability seems useful to me. >>> >> The gain is quite minimal.. If the first device fails (which doesn't >> happen too often I hope), then it will be read from the normal pool once >> and then stored in ARC/L2ARC again. It just behaves like a cache miss >> for that specific block... If this happens often enough to become a >> performance problem, then you should throw away that L2ARC device >> because it's broken beyond usability. >> >> > > Well if a L2ARC device fails there might be an unacceptable drop in delivered > performance. > If it were mirrored than a drop usually would be much smaller or there could > be no drop if a mirror had an option to read only from one side. > > Being able to mirror L2ARC might especially be useful once a persistent L2ARC > is implemented as after a node restart or a resource failover in a cluster > L2ARC will be kept warm. Then the only thing which might affect L2 > performance considerably would be a L2ARC device failure... > > > -- > Robert Milkowski > http://milek.blogspot.com > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
