On 12/11/2010 15:47, Chris Meyer wrote:
> Hi Steve,
> Thanks for the additional info about physical disks and datasets; and
> I understand the need to be compatible with ufs (and other file
> However, I think you're confusing terms. The following ZFS
> administration guide is helpful:
> A dataset is any of the following: clones, file systems, snapshots, or
> volumes. A clone is a copy of a snapshot. A volume is a physical
> What I propose is best for FreeNAS share points (on ZFS) are *file
> systems*. On non-ZFS systems, share points would have to be
> On ZFS, different share points might have different characteristics
> such as quotas, compression, multiple copies, checksumming and
> snapshot requirements.
I'd propose something simpler. Shares are done at or below the level of
a mointpoint. ZFS a moint point is the root of the zpool. It makes
sense to allow sharing of an entire zpool, even if parts of it have
different quotas, permissions, etc. I don't think we should
artificially tie the two together.
> On Sat, Dec 11, 2010 at 11:28 AM, Steven King<sking@...> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> Hi Chris,
>> Let me clarify a few things regarding terminology and what Sun meant
>> when they were creating ZFS.
>> You are correct that ZFS consists pool, a zpool. But lets start even
>> further back.
>> At the very bottom, you have disks. These disks come together to
>> create a virtual device. A zpool is created out of one or more virtual
>> devices, or vdev.
>> A pool then can be chopped up in to datasets. A dataset is essentially
>> a partition in old disk terms. A dataset is an optional entity. It is
>> completely a logical segregation of the zpool.
>> When you create 1 dataset, it does in fact appear to "consume" the
>> entire zpool. However this ideology is slightly incorrect. A dataset
>> doesn't consume anything like a partition does on a disk. A dataset
>> inherits all the properties of the container above it, in this case
>> the zpool. Therefore your dataset can use all the disk space that is
>> available to the zpool.
>> When you create a 2nd and 3rd dataset, you will find that they too can
>> use all the disk space that is available to the zpool. You would
>> usually put a quota on a dataset so that you don't have disk space
>> contention among the pools.
>> So lets look at your example in more detail
>> /Server<-- this is the zpool, it can also be used to store files and
>> be shared
>> /Server/Work<-- this is a dataset, it is a logical segregated area of
>> a zpool.
>> Your mention of the interface in r5648 is interesting. I am running
>> r5543. I don't believe that creating a share should also create a ZFS
>> dataset. This feature is meant to work with all kinds of file systems,
>> and not just ZFS. Also, you lose the flexibility of being able to use
>> the zpool itself for storage. Not everyone will have a complex dataset
>> setup with their ZFS pools.
>> I hope this better explains ZFS and its architecture. If you have any
>> questions regarding that please let me know. UI suggestions still
>> should be looked at by FreeNAS devs.
>> On 12/11/10 11:21 AM, Chris Meyer wrote:
>>> In FreeNAS r5648, there is no way to create additional mount points in
>> the UI.
>>> However, I think something more fundamental is wrong. So before added
>>> a new Ticket, I decided to bring up the discussion here.
>>> ZFS consists of pools (zpool) and file systems (zfs). File systems
>>> must be created within a pool. In addition, the first file system
>>> represents the entire pool.
>>> When FreeNAS creates shares, I think it should create a new file
>>> system within a particular pool and it is the sub-filesystem which
>>> should be the share, not the pool itself.
>>> So for instance, if I have the following pool and file systems:
>>> Pool: Server 1TB
>>> /Server<-- this represents the entire pool and shouldn't be a "share"
>>> The last three items (all created with zfs create ...) should be the
>>> Currently, there are two tabs for configuring storage and
>>> sharepoints.In the 'storage' tab, the UI shows the entries of the SQL
>>> table 'storage_mountpoint'. Unfortunately, the 'share' tab also shows
>>> the entries from 'storage_mountpoint'.
>>> So what should it be?
>>> I think 'storage' should show the entries in 'storage_volume'. These
>>> are the zpools. There should be one zpool per set of physical disks
>>> (i.e. per set of raided physical volumes).
>>> I think 'share' should show the entries in 'storage_mountpoint'.
>>> Creating a share should create a zfs within a zpool and that should be
>>> the share point.
>>> Finally, since a particular share point could be visible on the
>>> network as a 'smb' or an 'afp' share, the UI for deciding what 'share
>>> points' are shared for a specific protocol needs to be independent of
>>> the list of 'share points'. I.e. /mnt/Server/Work could be shared via
>>> both smb and afp. So perhaps a simple checkbox for each of the
>>> protocols on the 'share' page would be better?
>>> Oracle to DB2 Conversion Guide: Learn learn about native support for
>>> new data types, scalar functions, improved concurrency, built-in packages,
>>> OCI, SQL*Plus, data movement tools, best practices and more.
>>> Freenas-devel mailing list
>> - --
>> Steve King
>> Senior Linux Engineer - Advance Internet, Inc.
>> Cisco Certified Network Associate
>> CompTIA Linux+ Certified Professional
>> CompTIA A+ Certified Professional
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>> -----END PGP SIGNATURE-----
>> Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
>> new data types, scalar functions, improved concurrency, built-in packages,
>> OCI, SQL*Plus, data movement tools, best practices and more.
>> Freenas-devel mailing list
> Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
> new data types, scalar functions, improved concurrency, built-in packages,
> OCI, SQL*Plus, data movement tools, best practices and more.
> Freenas-devel mailing list