Hi Michael, What makes you think striping the SSDs would be faster than round-robin?
-marc On Thu, May 6, 2010 at 1:09 PM, Michael Sullivan <michael.p.sulli...@mac.com > wrote: > 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 >
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
