zfs discuss - Mar 2010 - What''s the advantage of using multiple filesystems in a pool

Hi guys, on my home server I have a variety of directories under a single
pool/filesystem, Cloud.

Things like
cloud/movies  -> 4TB
cloud/music     -> 100Gig
cloud/winbackups  -> 1TB
cloud/data   -> 1TB

etc.

After doing some reading, I see recomendations to have separate filesystem to
improve performance...but not sure how as it''s the same pool?

Can someone help me understand if/why I should use separate file systems for
these?

ta.
-- 
This message posted from opensolaris.org

tomwaters wrote:
> Hi guys, on my home server I have a variety of directories under a single
pool/filesystem, Cloud.
>
> Things like
> cloud/movies  -> 4TB
> cloud/music     -> 100Gig
> cloud/winbackups  -> 1TB
> cloud/data   -> 1TB
>
> etc.
>
> After doing some reading, I see recomendations to have separate filesystem
to improve performance...but not sure how as it''s the same pool?
>
> Can someone help me understand if/why I should use separate file systems
for these?
>
> ta.
>   
Obviously, having different filesystems gives you the ability to set 
different values for attributes, which may substantially improve 
performance or storage space depending on the data in that filesystem.  
As an example above, I would consider turning compression on for your 
cloud/winbackups and possibly for cloud/data, but definitely not for 
either cloud/movies (assuming mpeg4 or similar files) or cloud/music. 



-- 
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA

Thanks for that Erik.
-- 
This message posted from opensolaris.org

On Sun, February 28, 2010 21:24, tomwaters wrote:
> Hi guys, on my home server I have a variety of directories under a single
> pool/filesystem, Cloud.
>
> Things like
> cloud/movies  -> 4TB
> cloud/music     -> 100Gig
> cloud/winbackups  -> 1TB
> cloud/data   -> 1TB
>
> etc.
>
> After doing some reading, I see recomendations to have separate filesystem
> to improve performance...but not sure how as it''s the same pool?
It''s the same pool, so it''s the same IO bandwidth limits,
you''re right
about that.
> Can someone help me understand if/why I should use separate file systems
> for these?
It helps with management.  Quotas are by filesystem, for example.  Also
you can select compression and deduplication and eventually encryption per
filesystem.  Also you can snapshot them independently if you want.

And my environment has few enough filesystems that I''m not feeling the
pain from doing it; so I may not have thought it through completely.
-- 
David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

Also consider that you might not want to snapshot the entire pool.

For instance, if you have a media server, you may have a dump dir and a
torrent dir, you probably wouldn ''t want to snapshot this because it
changes
a lot and the snapshots could grow very large (or you may wish to snapshot
it but only for a couple days back)

Where you may wish to keep snapshots going back way further on your other
filesystems.

You may also want to use dedup on some filesystems and not others.  I also
keep separate filesystems for different uses on my network and then use
different ACL''s and cifs mounts, where i have a couple filesystems
which are
read write to everyone, and others which are read only and then each user
has thier own share which is only for them....For this type of stuff,
it''s
cool.


On Sun, Feb 28, 2010 at 10:24 PM, tomwaters <tomwaters at chadmail.com>
wrote:
> Hi guys, on my home server I have a variety of directories under a single
> pool/filesystem, Cloud.
>
> Things like
> cloud/movies  -> 4TB
> cloud/music     -> 100Gig
> cloud/winbackups  -> 1TB
> cloud/data   -> 1TB
>
> etc.
>
> After doing some reading, I see recomendations to have separate filesystem
> to improve performance...but not sure how as it''s the same pool?
>
> Can someone help me understand if/why I should use separate file systems
> for these?
>
> ta.
> --
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100301/27a60f25/attachment.html>

On Mar 1, 2010, at 7:42 AM, Thomas Burgess wrote:
> Also consider that you might not want to snapshot the entire pool.
Snapshots work on the dataset, not the pool (there is no "zpool
snapshot"
command :-) 

What usually trips me up is the auto-snapshot service and inherited properties.
You will want to make sure and not snapshot those file systems which are
"temporary" in nature.  You can do this with the advanced options
section
of the Time Slider Manager GUI, or by setting the com.sun:auto-snapshot
parameter appropriately on your datasets.
 -- richard

ZFS storage and performance consulting at http://www.RichardElling.com
ZFS training on deduplication, NexentaStor, and NAS performance
http://nexenta-atlanta.eventbrite.com (March 16-18, 2010)

On Sun, Feb 28 at 20:10, Erik Trimble wrote:
>Obviously, having different filesystems gives you the ability to set 
>different values for attributes, which may substantially improve 
>performance or storage space depending on the data in that 
>filesystem.  As an example above, I would consider turning 
>compression on for your cloud/winbackups and possibly for cloud/data, 
>but definitely not for either cloud/movies (assuming mpeg4 or similar 
>files) or cloud/music.
On Win7, the automatic backup service saves chunked ~200MB .zip files.
These are unlikely to compress very well.

--eric

-- 
Eric D. Mudama
edmudama at mail.bounceswoosh.org

On Mon, Mar 1, 2010 at 12:44 PM, Richard Elling <richard.elling at
gmail.com>wrote:
> On Mar 1, 2010, at 7:42 AM, Thomas Burgess wrote:
>
> > Also consider that you might not want to snapshot the entire pool.
>
> Snapshots work on the dataset, not the pool (there is no "zpool
snapshot"
> command :-)
>
> This is my entire point.  Somehow it must have been missed due to me not
using my words properly.

The OP asked what is the advantage of using separate filesystems instead of
just one big filesystem

My point is you may want to snapshot SOME stuff but not other stuff.

Even if there WAS a snapshot pool function.


> What usually trips me up is the auto-snapshot service and inherited
> properties.
> You will want to make sure and not snapshot those file systems which are
> "temporary" in nature.  You can do this with the advanced options
section
> of the Time Slider Manager GUI, or by setting the com.sun:auto-snapshot
> parameter appropriately on your datasets.
>  -- richard
>
> yes, this is very annoying when this happens =)


> ZFS storage and performance consulting at http://www.RichardElling.com
> ZFS training on deduplication, NexentaStor, and NAS performance
> http://nexenta-atlanta.eventbrite.com (March 16-18, 2010)
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100301/73cfb859/attachment.html>

Eric D. Mudama wrote:
> On Sun, Feb 28 at 20:10, Erik Trimble wrote:
>> Obviously, having different filesystems gives you the ability to set 
>> different values for attributes, which may substantially improve 
>> performance or storage space depending on the data in that 
>> filesystem.  As an example above, I would consider turning 
>> compression on for your cloud/winbackups and possibly for cloud/data, 
>> but definitely not for either cloud/movies (assuming mpeg4 or similar 
>> files) or cloud/music.
>
> On Win7, the automatic backup service saves chunked ~200MB .zip files.
> These are unlikely to compress very well.
>
> --eric
Let me just say:    Yuk.



-- 
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA

Ahh, interesting...once I get the data realatively stable in some of those
sub-folders I wil create a file system, move the data in there and setup the
snapshot for those that are relatively static...now I just need to do a load of
reading about snapshots!

Thanks again...sp much to learn.
-- 
This message posted from opensolaris.org

On Mon, March 1, 2010 22:58, Thomas Burgess wrote:
> On Mon, Mar 1, 2010 at 12:44 PM, Richard Elling
> <richard.elling at gmail.com>wrote:
>
>> On Mar 1, 2010, at 7:42 AM, Thomas Burgess wrote:
>>
>> > Also consider that you might not want to snapshot the entire pool.
>>
>> Snapshots work on the dataset, not the pool (there is no "zpool
>> snapshot"
>> command :-)
>>
>> This is my entire point.  Somehow it must have been missed due to me
not
> using my words properly.
>
> The OP asked what is the advantage of using separate filesystems instead
> of
> just one big filesystem
>
> My point is you may want to snapshot SOME stuff but not other stuff.
Yes, that''s the point.  I understood you the first time, but whatever;
if
significant numbers of people don''t, then finding a clearer way to say
it
is worth working on.
> Even if there WAS a snapshot pool function.
And there is, in most of our heads, such a function; since there''s a
filesystem at the pool level, and a "-r" switch :-).  I think of
"zfs
snapshot -r rememberthispointintime at rpoool" as "taking a snapshot
of
rpool".

I see that, if you''re using volumes and such, that thinking starts to
diverge more noticeably from reality.  But I''m not, in my data pool,
which
is the one I care about.

-- 
David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

On Mar 1, 2010, at 12:44, Richard Elling wrote:
> On Mar 1, 2010, at 7:42 AM, Thomas Burgess wrote:
>
>> Also consider that you might not want to snapshot the entire pool.
>
> Snapshots work on the dataset, not the pool (there is no "zpool  
> snapshot" command :-)
Wouldn''t a "zfs snapshot -r mypool" work?
> -r Recursively create snapshots of all descendent datasets.  
> Snapshots are taken atomically, so that all recursive snapshots  
> correspond to the same moment in time.
http://docs.sun.com/app/docs/doc/819-2240/zfs-1m

On Mar 2, 2010, at 2:48 PM, David Magda wrote:
> 
> On Mar 1, 2010, at 12:44, Richard Elling wrote:
> 
>> On Mar 1, 2010, at 7:42 AM, Thomas Burgess wrote:
>> 
>>> Also consider that you might not want to snapshot the entire pool.
>> 
>> Snapshots work on the dataset, not the pool (there is no "zpool
snapshot" command :-)
> 
> Wouldn''t a "zfs snapshot -r mypool" work?
That is just a shorthand for snapshotting (snapshooting? :-) datasets.
There still is no pool snapshot feature. Or to put it another way, there is
no way inside ZFS to replicate a pool.  This usually isn''t a big deal
because
your data is in the datasets.
 -- richard

ZFS storage and performance consulting at http://www.RichardElling.com
ZFS training on deduplication, NexentaStor, and NAS performance
http://nexenta-atlanta.eventbrite.com (March 16-18, 2010)

Hi Tom,

My input:
Create one file system per type of data to:
1. help organise your data logically
2. increase file system granularity which allows different file system
properties to be set per filesystem: such as copies, compression etc
3. allow separate shares to be easily setup: via CIFS (SMB/Samba-like) or NFS
4. allow finer control over user access depending on data type

For example I split my file systems into logical types like:
1. user home directory file systems
2. media (music, photo, video etc)
3. software archive
4. backups
5. test area

Also, within each of these file systems, ZFS allows file system nesting, to
allow better grouping.

If we assume the name ''tank'' for the pool name then the
default file system created when the pool is created is called
''tank''.

So for media file systems, I might create ''tank/media'' as the
base file system.
Within ''tank/media'' I can create
''tank/media/music'', ''tank/media/photo'',
''tank/media/video'' etc.

For the home file systems, I might create ''tank/home'' and then
nest ''tank/home/fred'', ''tank/home/wilma''
etc.

For easy, regular snapshotting of all the file systems, you can issue:
# zfs snapshot -r tank at 20100303

This will give snapshot names for each nested file system under the root
''tank'' file system like ''tank/home at
20100303'', ''tank/home/fred at 20100303'',
''tank/home/wilma at 20100303'', ''tank/media at
20100303'', ''tank/media/music at 20100303'',
''tank/media/photo at 20100303'', ''tank/media/video at
20100303'' etc.

If you want some more stuff to read then try these:
http://breden.org.uk/2008/03/08/home-fileserver-zfs-setup/
http://breden.org.uk/2009/05/10/home-fileserver-zfs-file-systems/
http://breden.org.uk/2008/03/02/a-home-fileserver-using-zfs/

You''ll also find stuff on snapshots, backups there too.

Hope this helps :)

Cheers,
Simon
-- 
This message posted from opensolaris.org

On Tue, Mar 02, 2010 at 03:14:04PM -0800, Richard Elling
wrote:
> That is just a shorthand for snapshotting (snapshooting? :-) datasets.
:-)
> There still is no pool snapshot feature. 
One could pick nits about "zpool split" ..

--
Dan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100305/5b0d0964/attachment.bin>

In addition to all the other good advice in the thread, I will
emphasise the benefit of having smaller snapshot granularity.  I have
found this to be one of the most valuable and comprelling reasons when
I have chosen to create a separate filesystem. 

If there''s data that changes often and I don''t really need to
keep,
(like say browser cache) putting that in separate filesystems lets me
free those snapshots sooner, and as a result keep more copies for
longer of other data I care more about (like my homedir).  Once the
snapshot is taken with them together in one filesystem, it can only be
freed together. 

--
Dan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100305/42d0b7a8/attachment.bin>