Some miscellaneous questions: * When you share a ZFS fs via NFS, what happens to files and filesystems that exceed the limits of NFS? * Is there a recommendation or some guidelines to help answer the question "how full should a pool be before deciding it''s time add disk space to a pool?" * Migrating pre-ZFS backups to ZFS backups: is there a better method than "restore the old backup into a ZFS fs, then back it up using "zfs send"? * Are ZFS quotas enforced assuming that compressed data is compressed, or uncompressed? The former seems to imply that the following would create a mess: 1) Turn on compression 2) Store data in the pool until the pool is almost full 3) Turn off compression 4) Read and re-write every file (thus expanding each file) * What block sizes will ZFS use? Is there an explanation somewhere about its method of choosing blocksize for a particular workload? This message posted from opensolaris.org
On Tue, May 23, 2006 at 02:34:30PM -0700, Jeff Victor wrote:> * When you share a ZFS fs via NFS, what happens to files and > filesystems that exceed the limits of NFS?What limits do you have in mind? I''m not an NFS expert, but I think that NFSv4 (and probably v3) supports 64-bit file sizes, so there would be no limit mismatch there.> * Is there a recommendation or some guidelines to help answer the > question "how full should a pool be before deciding it''s time add disk > space to a pool?"I''m not sure, but I''d guess around 90%.> * Migrating pre-ZFS backups to ZFS backups: is there a better method > than "restore the old backup into a ZFS fs, then back it up using "zfs > send"?No.> * Are ZFS quotas enforced assuming that compressed data is compressed, > or uncompressed?Quotas apply to the amount of space used, after compression. This is the space reported by ''zfs list'', ''zfs get used'', ''df'', ''du'', etc.> The former seems to imply that the following would create a mess: > 1) Turn on compression > 2) Store data in the pool until the pool is almost full > 3) Turn off compression > 4) Read and re-write every file (thus expanding each file)Since this example doesn''t involve quotas, their behavior is not applicable here. In this example, there will be insufficient space in the pool to store your data, so your write operation will fail with ENOSPC. Perhaps a messy situation, but I don''t see any alternative. If this is a concern, don''t use compression. If you filled up a filesystem''s quota rather than a pool, the behavior would be the same except you would get EDQUOT rather than ENOSPC.> * What block sizes will ZFS use? Is there an explanation somewhere > about its method of choosing blocksize for a particular workload?Files smaller than 128k will be stored in a single block, whose size is rounded up to the nearest sector (512 bytes). Files larger than 128k will be stored in multiple 128k blocks (unless the recordsize property has been set -- see the zfs(1m) manpage for an explanation of this). Thanks for using zfs! --matt
>On Tue, May 23, 2006 at 02:34:30PM -0700, Jeff Victor wrote: >> * When you share a ZFS fs via NFS, what happens to files and >> filesystems that exceed the limits of NFS? > >What limits do you have in mind? I''m not an NFS expert, but I think >that NFSv4 (and probably v3) supports 64-bit file sizes, so there would >be no limit mismatch there.NFSv3 does support 64 bit filesizes also (that was one major motivation for NFSv3) Filesystem sizes never mattered much for NFS; even NFSv2 supported really large filesystems: it never looks at whole filesystems except in a few calls which support "df" (so df output could look funny in the worst case scenario) Casper
Matthew Ahrens wrote:> On Tue, May 23, 2006 at 02:34:30PM -0700, Jeff Victor wrote: >> * When you share a ZFS fs via NFS, what happens to files and >> filesystems that exceed the limits of NFS? > > What limits do you have in mind? I''m not an NFS expert, but I think > that NFSv4 (and probably v3) supports 64-bit file sizes, so there would > be no limit mismatch there.yes v3 supports largefile(5) sized files.>> * Is there a recommendation or some guidelines to help answer the >> question "how full should a pool be before deciding it''s time add disk >> space to a pool?" > > I''m not sure, but I''d guess around 90%. > >> * Migrating pre-ZFS backups to ZFS backups: is there a better method >> than "restore the old backup into a ZFS fs, then back it up using "zfs >> send"? > > No.I''d say that it depends for the "then back it up" part. It depends on what backup software you use today. If you use something like Legato Networker or Veritas Netbackup or anything else that just walks the file system using POSIX APIs, then keep using that. Be aware though that they may not pickup on ZFS ACLs yet and they won''t save the zfs data set config, ie compression, checksum etc. -- Darren J Moffat
Matthew Ahrens wrote:> On Tue, May 23, 2006 at 02:34:30PM -0700, Jeff Victor wrote: > >>* When you share a ZFS fs via NFS, what happens to files and >>filesystems that exceed the limits of NFS? > > What limits do you have in mind? I''m not an NFS expert, but I think > that NFSv4 (and probably v3) supports 64-bit file sizes, so there would > be no limit mismatch there.In case your question wasn''t rhetorical: I was forwarding these questions from a partner company. I think the perception that ZFS is much bigger than everything else **in every way** got ahead of reality. -- -------------------------------------------------------------------------- Jeff VICTOR Sun Microsystems jeff.victor @ sun.com OS Ambassador Sr. Technical Specialist Solaris 10 Zones FAQ: http://www.opensolaris.org/os/community/zones/faq --------------------------------------------------------------------------