<div dir="ltr">Hi.<br><br>Thanks for your detailed answers. I'd like to clarify several points:<br><br><div class="gmail_quote">2008/12/3 Keith Freedman <span dir="ltr"><<a href="mailto:freedman@freeformit.com">freedman@freeformit.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'm not sure there's an official recommendation.<br>
I use XFS with much success.<br>
</blockquote><div><br>Is XFS suitable for massive writing / occasional reading?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
I think the choice of underlying filesystem depends highly on the types of data you'll be storing and how you'll be storing the info.<br>
If it's primarily read data, then a filesystem with journaling capabilities may not provide much benefit. If you'll have lots of files in few directories then a filesystem with better large directory metrix would be ideal, etc... Gluster depends on the underlying filesystem, and will work no matter what that filesystem is provided it supports extended attributes.<br>
</blockquote><div><br>I'm going to store mostly large files (100+ MB), with massive writing, and only occasional read operations.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I've found XFS works great for most purposes. If you're on Solaris, I'd recommend ZFS. but It seems people are fond of ReiserFS, but you could certainly use EXT3 with extended attributes enabled and be just fine most likely.<br>
</blockquote><div><br>I'm actually prefer to stay on Linux. How well XFS compares to EXT3 in the environment that I described?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
as for LVM. again, this really depends what you want to do with the data.<br>
If you need to use multiple physical devices/partitions to present just one to gluster you can do that and use LVM to manage your resizing of the single logical volume.</blockquote><div><br>This was the first idea I though about, as I'm going to use 4 disks per server. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Alternatively, you could use gluster's Unify translator to present one effective large/consolidated volume which can be made up of multiple devices/partitions.<br>
</blockquote><div><br>I think I read somewhere in this mailing list that there is a migration from Unity to DHT in GlusterFS (whichever it means) in the coming 1.4. If Unity is the legacy approach, what is the relevant solution for 1.4 (DHT)?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
In this scenario, you could potentially have multiple underlying configurations. You could Unify xfs, reiser, and ext3 filesystems into one gluster filesystem.<br>
<br>
as for RAID, again, the faster and more appropriately configured the underlying system for your data requirements, the better off you will be. If you're going to use gluster's AFR translator, then I'd not bother with hardware raid/mirroring and just use RAID0 stripes, however, if you have the money, and can afford to do RAID0+1, that's always a huge benefit on read performance. Of course, if you're in a high write environment, then there's no real added value so it's not worth doing.<br>
</blockquote><div><br>Couple of points here:<br>1) Thanks to AFR, I actually don't need any fault-tolerant raid (like mirror), so it's only recommeded in high-volume read enviroments, which is not the case here. Is this correct?<br>
<br>2) Isn't LVM (or GlusterFS own solution) much better then RAID 0 in sense that if one of the disks go, the volume still continues to work? This contrary to RAID where the whole volume goes down?<br><br>3) Continuing 2, I think I actually meant JBOD - where you just connect all the drives and make them look as a single device, rather then stripping.<br>
<br>If you could clarfy the recommended approach, it would be great.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
this doesn't realy answer your question, but hopefully it helps.<div><div></div><div class="Wj3C7c"><br>
<br>
</div></div></blockquote><div><br>Thanks again for your help.<br><br>Regards.<br></div></div></div>