3 ms·
I have run into this problem myself. It is actually a problem with the Solaris ls and related utilities, and not with ZFS. I solved it by compiling some relevan
by tensor 17y ago
I have run into this problem myself. It is actually a problem with the Solaris ls and related utilities, and not with ZFS. I solved it by compiling some relevant GNU versions of utilities like find, which have some important performance improvements on this front.
As for working with many small files, in my experience ZFS has been far better than xfs (I do not use reiserFS due to previous stability issues I experienced with it). One particular example was a user who had over a million files in one directory. This caused all our backup software to fail. After moving to ZFS, I could send and receive these files between servers without problem. I could list the files easily enough as well, after installing the aforementioned GNU versions with Blastwave.
I believe there is a GNU version of ls in Blastwave as well that Steve could try.
- tensor 17y agoOh wait, this is a SAN. I assume then that the ls is over the network and not done on a Solaris box? If that is the case, then it is very much some sort of non-typical problem. I guess there are also other factors here. Were the SATA drives connected via a network as well? Does the SAN run NFS or something else? At any rate, it certainly doesn't take minutes to list 6000 files. My example above was actually on 4 million files. Extrapolating from 6000 to 4 million, my listing should have taken 11 hours. It may have with the default utilities, but it took no where near that long when I replaced the utilities with GNU versions. For reference, this was directly on the Solaris machine which had the ZFS pool attached via SATA.
- nailer 17y agoIf a GNU version of ls is required to take advantage of Sun's years-of-effort filesystem in a fairly reasonable situation for a high performance filesystem, Sun has a serious problem.