Interesting, at least to me, the part where/ "this storage node is very small (~100TB)" /:) Anyway, how are you using your ZFS? Are you creating volumes and present them to end-nodes over iscsi/fiber , nfs, or other? Could be helpfull to use some sort of cluster filesystem to have some more control in the "balance"of writes across devices? I'm just thinking out loud, but if your end-nodes access a zvol over iscsi, could you format that zvol in the end-node with LustreFS, and use the features of the LustreFS?
Bruno Jesse Stroik wrote: > >>> There are, of course, job types where you use the same set of data >>> for multiple jobs, but having even a small amount of extra memory >>> seems to be very helpful in that case, as you'll have several nodes >>> reading the same data at roughly the same time. >> >> Yep. More, faster memory closer to the consumer is always better. >> You could buy machines with TBs of RAM, but high-end x86 boxes top >> out at 512 GB. > > > That was our previous approach. We're testing doing it with > relatively cheap, consumer-level Sun hardware (ie: machines with 64 or > maybe 128GB of memory today) that can be easily expanded as the pool's > purpose changes. > > I know what our options are for increasing performance if we want to > increase the budget. My question isn't, "I have this data set, can > you please tell me how to buy and configure a system." My question > is, "how does ZFS balance pools during writes, and how can I force it > to balance data I want balanced in the way I want it balanced?" And > if the answer to that question is, "you can't reliably do this," then > that is acceptable. It's something I would like to be able to plan > around. > > Right now, this storage node is very small (~100TB) and in testing. I > want to know how I can solve problems like this as we scale it up into > a full fledged SAN that holds a lot more data and gets moved into > production. Knowing the limitations of ZFS is a critical part of > properly designing and expanding the system. > > Best, > Jesse > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
