Hi Marc, Well, if you are striping over multiple devices the you I/O should be spread over the devices and you should be reading them all simultaneously rather than just accessing a single device. Traditional striping would give 1/n performance improvement rather than 1/1 where n is the number of disks the stripe is spread across.
The round-robin access I am referring to, is the way the L2ARC vdevs appear to be accessed. So, any given object will be taken from a single device rather than from several devices simultaneously, thereby increasing the I/O throughput. So, theoretically, a stripe spread over 4 disks would give 4 times the performance as opposed to reading from a single disk. This also assumes the controller can handle multiple I/O as well or that you are striped over different disk controllers for each disk in the stripe. SSD's are fast, but if I can read a block from more devices simultaneously, it will cut the latency of the overall read. On 7 May 2010, at 02:57 , Marc Nicholas wrote: > 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... > > > >
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
