[ale] UFS/SDS v VxFS/VxVM (was: ext3 v reiserfs)
matty91 at bellsouth.net
matty91 at bellsouth.net
Mon Sep 15 14:07:21 EDT 2003
On Mon, 15 Sep 2003, Dylan Northrup wrote:
> A long time ago, (14.09.03), in a galaxy far, far away, matty91 at bellsouth.n...:
>
> :=On Sun, 14 Sep 2003, Greg wrote:
> :=
> :=> Since you can strip the logs out of ext3 and get ext files, which can be
> :=> exported to other OS's which have no ext3/reiserfs support, that could be a
> :=> compelling reason to use ext3 - the ability to go to a more universally
> :=> acceptable format. However I think that only the BSD's are this way, as
> :=> they use SoftUpdates to the ffs to solve the problems that logging are
> :=> supposed to handle. Don't know about Solaris.
> :=
> :=Solaris incorporates UFS logging into their UFS implementation. For large
> :=file systems, I would recommend deploying VxFS.
>
> Depends on what your system requirements are. The coupling of VxFS and VxVM
> gives you some advantages and power you don't necessarily get when you
> combine UFS and SDS (Sun's Volume Manager). Performance-wise I have yet to
> run into a situation where UFS was slower than VxFS. If you set up logging
> with UFS you match the "dirty startup" times of VxFS. The one clear cut
Extent-based allocation really starts to shine when you start moving to
large databases (sequential and/or random access), big file servers, or
anything that can't be accessed directly with an inode (UFS still does
block based allocation, and following sindirect pointers takes time and
resources). VxFS also provides a more refined snapshot mechanism, online
extent reorganization, Quick I/O (provides pretty close to raw disk
performance), and a pretty slick clustered file system.
> advantage VxFS has (that I've made use of) is it's ability to shrink
> volumes. . . but to be honest, I've grown volumes 100 times more frequently
> than I've shrunk them. And having volumes that are too small is a sign of
> poor planning in the first case (whether it's on the part of the technical
> staff or on the part of the folks who provided requirements to the technical
> staff).
>
> For volume management (which should play a big role in what file system you
> select under Solaris) I find SDS to be more straightforward than VxVM. I
> don't need to do two reboots to mirror my root disks (install VxVM/VxFS,
> reboot, encapsulate root disk, reboot, begin mirroring). I am using a
> native FS on the host so I don't need any specific kernel modules just so I
> can boot up. I don't need to uninstall VxFS/VxVM when upgrading a system.
> And, for my personal use, Solaris 9 has SDS integrated into the OS so it's
> free and I don't need to pay for a node-locked license for the Vx stuff that
> I can't transfer to a new box without bothering with the hassle of
> contacting Veritas if/when I want to upgrade my iron.
>
If you have ever used Disksuite with disksets or large amounts of disk
devices, you would grow to love VxVM. Disksets are clunky, soft
partitioning is not real straight forward (VxVM DIDs rock), and VxVM
is a piece of cake to manage (Disksutie is as well). I am not sure about
you, but how may times have you actually performed a Solaris upgrade? VxVM
costs money because it provides a ton of functionality and SAN management
capabilities not built into SDS.
> --
> Dylan Northrup <*> docx at io.com <*> http://www.io.com/~docx/
> "Harder to work, harder to strive, hard to be glad to be alive, but it's
> really worth it if you give it a try." -- Cowboy Mouth, 'Easy'
>
Ryan Matteson - UNIX Administrator | GPG ID: 92D5DFFF
Public Key: http://www.daemons.net/~matty/public_key.txt
Fingerprint = 4BEC 6145 30A6 BCE6 5602 FF11 4954 165D 92D5 DFFF
More information about the Ale
mailing list