Re: [zfs-discuss] what to put on zfs
Bennett, Steve wrote: A slightly different tack now... what filesystems is it a good (or bad) idea to put on ZFS? root - NO (not yet anyway) home - YES (although the huge number of mounts still scares me a bit) Why ? I've seen Solaris systems with upwards of 10,000 mounts in /home via the automounter alone. /usr - possible? /var - possible? swap - no? You can swap on a zvol today but note that you can't yet use a zvol as a dump device. Is there any advantage in having multiple zpools over just having one and allocating all filesystems out of it? Obviously if you wanted (for example) /export/home to be raidz and /usr to be mirror you would have to, but are there other considerations beyond that? Having a separate pool for the operating system and one for your data might be a good idea. This allows you to move the data else where later much easier. -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: what to put on zfs
> It is likely that "best practice" will be to separate > the root pool (that is, the pool where dataset are > allocated) On a system with plenty of disks it is a good idea. I started doing this on my laptop, and later decided to combine root and data into one pool. The filesystem boundary gave me sufficent separation. Having separate pools made me have 2 partitions with fixed boundries, which limited ZFS's flexibility. Doug This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zfs filesystem/path names args with leading /
What danger is there in stripping off the leading / from zfs command args and using what is left as a filesystem name? Quite often I do a quick copy-paste to get from df output to the zfs command line and every time I need to re-edit the command line because the copy-paste takes the leading / with it. Darren ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs filesystem/path names args with leading /
On Mon, 2006-07-03 at 18:02 +0800, Darren Reed wrote: > What danger is there in stripping off the leading / from zfs > command args and using what is left as a filesystem name? If I'm understanding you correctly, then you can't do that, as the mountpoint isn't always the same as the name of the filesystem. For example: [EMAIL PROTECTED] df | grep local /usr/local (space/usrlocal):17092419 blocks 17092419 files /usr/local/foo (space/usrlocal/foo):17092419 blocks 17092419 files Of course, there's nothing stopping you taking the middle field (enclosed in parenthesis) from df instead. does this help ? cheers, tim -- Tim Foster, Sun Microsystems Inc, Operating Platforms Group Engineering Operationshttp://blogs.sun.com/timf ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs filesystem/path names args with leading /
Tim Foster wrote: On Mon, 2006-07-03 at 18:02 +0800, Darren Reed wrote: What danger is there in stripping off the leading / from zfs command args and using what is left as a filesystem name? If I'm understanding you correctly, then you can't do that, as the mountpoint isn't always the same as the name of the filesystem. For example: [EMAIL PROTECTED] df | grep local /usr/local (space/usrlocal):17092419 blocks 17092419 files /usr/local/foo (space/usrlocal/foo):17092419 blocks 17092419 files Of course, there's nothing stopping you taking the middle field (enclosed in parenthesis) from df instead. Well, I use "df -kl", but commands such as "df" will work just the same if I use "." or "/" or "/dev/dsk/c0t3d0s0" (and all three are the same.) Yes, arguably I am cut-past'ing the wrong part of the output.. I suppose what I'm questioning is, whether or not there is any real danger in zfs converting /usr/local to usr/local and then trying to do a delete of the filesystem usr/local. I suppose this could mounted in /opt/local and be not what I wanted... But in the case where the ZFS mountpoint is the ZFS filesystem name (plus a leading /), why not allow both names to mean the same? Darren ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] [raidz] file not removed: No space left on device
On a system still running nv_30, I've a small RaidZ filled to the brim: 2 3 [EMAIL PROTECTED] pts/9 ~ 78# uname -a SunOS mir 5.11 snv_30 sun4u sparc SUNW,UltraAX-MP 0 3 [EMAIL PROTECTED] pts/9 ~ 50# zfs list NAME USED AVAIL REFER MOUNTPOINT mirpool1 33.6G 0 137K /mirpool1 mirpool1/home 12.3G 0 12.3G /export/home mirpool1/install 12.9G 0 12.9G /export/install mirpool1/local1.86G 0 1.86G /usr/local mirpool1/opt 4.76G 0 4.76G /opt mirpool1/sfw 752M 0 752M /usr/sfw Trying to free some space is meeting a lot of reluctance, though: 0 3 [EMAIL PROTECTED] pts/9 ~ 51# rm debug.log rm: debug.log not removed: No space left on device 0 3 [EMAIL PROTECTED] pts/9 ~ 55# rm -f debug.log 2 3 [EMAIL PROTECTED] pts/9 ~ 56# ls -l debug.log -rw-r--r-- 1 th12242027048 Jun 29 23:24 debug.log 0 3 [EMAIL PROTECTED] pts/9 ~ 58# :> debug.log debug.log: No space left on device. 0 3 [EMAIL PROTECTED] pts/9 ~ 63# ls -l debug.log -rw-r--r-- 1 th12242027048 Jun 29 23:24 debug.log There are no snapshots, so removing/clearing the files /should/ be a way to free some space there. Of course this is the same filesystem where zdb dumps core - see: *Synopsis*: zdb dumps core - bad checksum http://bt2ws.central.sun.com/CrPrint?id=6437157 *Change Request ID*: 6437157 (zpool reports the RaidZ pool as healthy while zdb crashes with a 'bad checksum' message.) This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] [raidz] file not removed: No space left on device
Hi, of course, the reason for this is the copy-on-write approach: ZFS has to write new blocks first before the modification of the FS structure can reflect the state with the deleted blocks removed. The only way out of this is of course to grow the pool. Once ZFS learns how to free up vdevs this may become a better solution because you can then shrink the pool again after the rming. I expect many customers to run into similar problems and I've already gotten a number of "what if the pool is full" questions. My answer has always been "No file system should be used up more than 90% for a number of reasons", but in practice this is hard to ensure. Perhaps this is a good opportunity for an RFE: ZFS should reserve enough blocks in a pool in order to always be able to rm and destroy stuff. Best regards, Constantin P.S.: Most US Sun employees are on vacation this week, so don't be alarmed if the really good answers take some time :). Tatjana S Heuser wrote: > On a system still running nv_30, I've a small RaidZ filled to the brim: > > 2 3 [EMAIL PROTECTED] pts/9 ~ 78# uname -a > SunOS mir 5.11 snv_30 sun4u sparc SUNW,UltraAX-MP > > 0 3 [EMAIL PROTECTED] pts/9 ~ 50# zfs list > NAME USED AVAIL REFER MOUNTPOINT > mirpool1 33.6G 0 137K /mirpool1 > mirpool1/home 12.3G 0 12.3G /export/home > mirpool1/install 12.9G 0 12.9G /export/install > mirpool1/local1.86G 0 1.86G /usr/local > mirpool1/opt 4.76G 0 4.76G /opt > mirpool1/sfw 752M 0 752M /usr/sfw > > Trying to free some space is meeting a lot of reluctance, though: > 0 3 [EMAIL PROTECTED] pts/9 ~ 51# rm debug.log > rm: debug.log not removed: No space left on device > 0 3 [EMAIL PROTECTED] pts/9 ~ 55# rm -f debug.log > 2 3 [EMAIL PROTECTED] pts/9 ~ 56# ls -l debug.log > -rw-r--r-- 1 th12242027048 Jun 29 23:24 debug.log > 0 3 [EMAIL PROTECTED] pts/9 ~ 58# :> debug.log > debug.log: No space left on device. > 0 3 [EMAIL PROTECTED] pts/9 ~ 63# ls -l debug.log > -rw-r--r-- 1 th12242027048 Jun 29 23:24 debug.log > > There are no snapshots, so removing/clearing the files /should/ > be a way to free some space there. > > Of course this is the same filesystem where zdb dumps core > - see: > > *Synopsis*: zdb dumps core - bad checksum > http://bt2ws.central.sun.com/CrPrint?id=6437157 > *Change Request ID*: 6437157 > > (zpool reports the RaidZ pool as healthy while > zdb crashes with a 'bad checksum' message.) > > > This message posted from opensolaris.org > ___ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- Constantin GonzalezSun Microsystems GmbH, Germany Platform Technology Group, Client Solutionshttp://www.sun.de/ Tel.: +49 89/4 60 08-25 91 http://blogs.sun.com/constantin/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Thumper on (next) Tuesday?
Notice there's a product announcement on Tuesday: http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/06-30-2006/0004390495&EDATE= and Jonathan mentioned Thumper was due for release at the end of june: http://blogs.sun.com/roller/page/jonathan?entry=phase_2 With ZFS officitally supported now, I'd say The Stars Are Right -- Rasputin :: Jack of All Trades - Master of Nuns http://number9.hellooperator.net/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS Questions. (RAID-Z questions actually)
Hello Gurus; I've been playing with ZFS and reading the materials, BLOGS and FAQs. It's an awesome FS and I just wish that Sun would evangelize a little bit more. But that's another story. I'm writing here to ask a few very simple questions. I am able to understand the RAID-5 write hole and it's implications. I am however, not able to grasp the concept of RAID-Z. More specifically the following statements which were repeated over and over again across many BLOGS, FAQ and reading materials... From Jeff Bonwick's weblog (http://blogs.sun.com/roller/page/bonwick/20051118) "RAID-Z is a data/parity scheme like RAID-5, but it uses dynamic stripe width. Every block is its own RAID-Z stripe, regardless of blocksize. This means that every RAID-Z write is a full-stripe write. This, when combined with the copy-on-write transactional semantics of ZFS, completely eliminates the RAID write hole. RAID-Z is also faster than traditional RAID because it never has to do read-modify-write." I understand the copy-on-write thing. That was very well illustrated in "ZFS The Last Word in File Systems" by Jeff Bonwick. But if every block is it's own RAID-Z stripe, if the block is lost, how does ZFS recover the block??? Is the stripe parity (as opposed to block checksum which I understand) stored somewhere else or within the same black But how exactly does "every RAID-Z write is a full stripe write" works? More specifically, if in a 3 disk RAID-Z configuration, if one disk fails completely and is replaced, exactly how does the "metadata driven reconstruction" recover the newly replaced disk? It goes on...(and very similar statements from other sites and materials..) "Well, the tricky bit here is RAID-Z reconstruction. Because the stripes are all different sizes, there's no simple formula like "all the disks XOR to zero." You have to traverse the filesystem metadata to determine the RAID-Z geometry. Note that this would be impossible if the filesystem and the RAID array were separate products, which is why there's nothing like RAID-Z in the storage market today. You really need an integrated view of the logical and physical structure of the data to pull it off." Every stripe is different size? Is this because ZFS adapts to the nature of the I/O coming to it? Could someone elaborate more on the statement "metadata drives reconstruction"... (I am familiar with metadata. More specifically, I am familiar with UFS and it's methodology. But the above statement I am having a little difficulty) The following from zfs admin 0525.. "In RAID-Z,ZFS uses variable-width RAID stripes so that all writes are full-stripe writes.This design is only possible because ZFS integrates le system and device management in such a way that the le system s metadata has enough information about the underlying data replication model to handle variable-width RAID stripes." I could use a little help here... I apologies if these questions are elementary ones Warmest Regards Steven Sim Fujitsu Asia Pte. Ltd. _ This e-mail is confidential and may also be privileged. If you are not the intended recipient, please notify us immediately. You should not copy or use it for any purpose, nor disclose its contents to any other person. Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Questions. (RAID-Z questions actually)
>I understand the copy-on-write thing. That was very well illustrated in >"ZFS The Last Word in File Systems" by Jeff Bonwick. > >But if every block is it's own RAID-Z stripe, if the block is lost, how >does ZFS recover the block??? You should perhaps not take "block" literally; the block is written as part of a single transaction on all disks of the RAID-Z group. Only when the block is stored on disk, the bits referencing them will be written. For the whole block to be lost, all disks need to be lost or the transaction must not occur. >Is the stripe parity (as opposed to block checksum which I understand) >stored somewhere else or within the same black Parts of the block are written to each disk; the parity is written to the parity disk. >But how exactly does "every RAID-Z write is a full stripe write" works? >More specifically, if in a 3 disk RAID-Z configuration, if one disk >fails completely and is replaced, exactly how does the "metadata driven >reconstruction" recover the newly replaced disk? The metadata driven reconstruction will take the ueberblock and from there it will re-read the other disks and reconstruct the parity while also verifying checksums. Not all data needs to be read and not all parity needs to be computed; only the bits of disks which are actually in use are verified and have their parity recomputed. >"Well, the tricky bit here is RAID-Z reconstruction. Because the >stripes are all different sizes, there's no simple formula like "all the >disks XOR to zero." You have to traverse the filesystem metadata to >determine the RAID-Z geometry. Note that this would be impossible if the >filesystem and the RAID array were separate products, which is why >there's nothing like RAID-Z in the storage market today. You really need >an integrated view of the logical and physical structure of the data to >pull it off." > >Every stripe is different size? Is this because ZFS adapts to the nature >of the I/O coming to it? It's because the blocks written are all of different sizes. So if you write a 128K block on a 3 way RAID-Z, this can be written as 2x64K of data + 1x64K of parity. (Though I must admit that in such a scheme the disks still XOR to zero, at least the bits of disk used) Casper ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs filesystem/path names args with leading /
On Mon, Jul 03, 2006 at 06:43:59PM +0800, Darren Reed wrote: > > Well, I use "df -kl", but commands such as "df" will work just > the same if I use "." or "/" or "/dev/dsk/c0t3d0s0" (and all three > are the same.) > > Yes, arguably I am cut-past'ing the wrong part of the output.. > > I suppose what I'm questioning is, whether or not there is any > real danger in zfs converting /usr/local to usr/local and then > trying to do a delete of the filesystem usr/local. I suppose this > could mounted in /opt/local and be not what I wanted... > > But in the case where the ZFS mountpoint is the ZFS filesystem > name (plus a leading /), why not allow both names to mean the same? A better solution would be fixing this RFE: 6260523 want 'zfs list ' Which could also be expanded to other zfs(1M) commands. This would do the statvfs()/getmntany() to find the associated zfs dataset, regardless of whether it matches the mountpoint or not. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] [raidz] file not removed: No space left on device
You don't need to grow the pool. You should always be able truncate the file without consuming more space, provided you don't have snapshots. Mark has a set of fixes in testing which do a much better job of estimating space, allowing us to always unlink files in full pools (provided there are no snapshots, of course). This provides much more logical behavior by reserving some extra slop. - Eric On Mon, Jul 03, 2006 at 02:23:06PM +0200, Constantin Gonzalez wrote: > Hi, > > of course, the reason for this is the copy-on-write approach: ZFS has > to write new blocks first before the modification of the FS structure > can reflect the state with the deleted blocks removed. > > The only way out of this is of course to grow the pool. Once ZFS learns > how to free up vdevs this may become a better solution because you can then > shrink the pool again after the rming. > > I expect many customers to run into similar problems and I've already gotten > a number of "what if the pool is full" questions. My answer has always been > "No file system should be used up more than 90% for a number of reasons", but > in practice this is hard to ensure. > > Perhaps this is a good opportunity for an RFE: ZFS should reserve enough > blocks in a pool in order to always be able to rm and destroy stuff. > > Best regards, >Constantin > > P.S.: Most US Sun employees are on vacation this week, so don't be alarmed > if the really good answers take some time :). -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: Re: Re: Supporting ~10K users on ZFS
> > Currently, I'm using executable maps to create zfs > home directories. > > Casper Casper, anything you can share with us on that? Sounds interesting. thanks, -- MikeE This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Re: Re: Supporting ~10K users on ZFS
>>
>> Currently, I'm using executable maps to create zfs
>> home directories.
>>
>> Casper
>
>
>Casper, anything you can share with us on that? Sounds interesting.
It's really very lame:
Add to /etc/auto_home as last entry:
+/etc/auto_home_import
And install /etc/auto_home_import as executable script:
#!/bin/ksh -p
#
# Find home directory; create directories under /export/home
# with zfs if they do not exist.
#
hdir=$(echo ~$1)
if [[ "$hdir" != /home/* ]]
then
# Not a user with a valid home directory.
exit
fi
#
# At this point we have verified that "$1" is a valid
# user with a home of the form /home/username.
#
h=/export/home/"$1"
if [ -d "$h" ]
then
echo "localhost:$h"
exit 0
fi
/usr/sbin/zfs create "export/home/$1" || exit 1
cd /etc/skel
umask 022
/bin/find . -type f | while read f; do
f=$(basename $f)
# Remove optional local prefix /etc/skel files.
f="$h/${f##local}"
cp "$f" "$t"
chown "$1" "$t"
done
chown "$1" $h
echo "localhost:$h"
exit 0
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Re: Re: Supporting ~10K users on ZFS
On 7/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>
>> Currently, I'm using executable maps to create zfs
>> home directories.
>>
>> Casper
>
>
>Casper, anything you can share with us on that? Sounds interesting.
It's really very lame:
Add to /etc/auto_home as last entry:
+/etc/auto_home_import
And install /etc/auto_home_import as executable script:
#!/bin/ksh -p
#
# Find home directory; create directories under /export/home
# with zfs if they do not exist.
#
hdir=$(echo ~$1)
if [[ "$hdir" != /home/* ]]
then
# Not a user with a valid home directory.
exit
fi
#
# At this point we have verified that "$1" is a valid
# user with a home of the form /home/username.
#
h=/export/home/"$1"
if [ -d "$h" ]
then
echo "localhost:$h"
exit 0
fi
/usr/sbin/zfs create "export/home/$1" || exit 1
another way to do this that is quicker if you are executing this often
is create a user directory with all the skel files in place, snapshot
it, then clone that directory and chown the files.
zfs snapshot /export/home/[EMAIL PROTECTED] export/home/$1 ; chown -R
/export/home/$1
James Dickens
uadmin.blogspot.com
cd /etc/skel
umask 022
/bin/find . -type f | while read f; do
f=$(basename $f)
# Remove optional local prefix /etc/skel files.
f="$h/${f##local}"
cp "$f" "$t"
chown "$1" "$t"
done
chown "$1" $h
echo "localhost:$h"
exit 0
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Re: Re: Supporting ~10K users on ZFS
On 7/3/06, James Dickens <[EMAIL PROTECTED]> wrote:
On 7/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> >>
> >> Currently, I'm using executable maps to create zfs
> >> home directories.
> >>
> >> Casper
> >
> >
> >Casper, anything you can share with us on that? Sounds interesting.
>
>
> It's really very lame:
>
>
> Add to /etc/auto_home as last entry:
>
> +/etc/auto_home_import
>
> And install /etc/auto_home_import as executable script:
>
> #!/bin/ksh -p
> #
> # Find home directory; create directories under /export/home
> # with zfs if they do not exist.
> #
>
> hdir=$(echo ~$1)
>
> if [[ "$hdir" != /home/* ]]
> then
> # Not a user with a valid home directory.
> exit
> fi
>
> #
> # At this point we have verified that "$1" is a valid
> # user with a home of the form /home/username.
> #
> h=/export/home/"$1"
> if [ -d "$h" ]
> then
> echo "localhost:$h"
> exit 0
> fi
>
> /usr/sbin/zfs create "export/home/$1" || exit 1
another way to do this that is quicker if you are executing this often
is create a user directory with all the skel files in place, snapshot
it, then clone that directory and chown the files.
zfs snapshot /export/home/[EMAIL PROTECTED] export/home/$1 ; chown -R
/export/home/$1
oops i guess i need more coffee
zfs clone /export/home/[EMAIL PROTECTED] export/home/$1 ; chown -R
/export/home/$1
James Dickens
uadmin.blogspot.com
>
> cd /etc/skel
> umask 022
> /bin/find . -type f | while read f; do
> f=$(basename $f)
> # Remove optional local prefix /etc/skel files.
> f="$h/${f##local}"
> cp "$f" "$t"
> chown "$1" "$t"
> done
>
> chown "$1" $h
>
> echo "localhost:$h"
> exit 0
>
> ___
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Re: Re: Supporting ~10K users on ZFS
I am new to zfs and do not understand the reason that you would want to create a separate file system for each home directory. Can some one explain to me why you would want to do this?
On 7/3/06, James Dickens <[EMAIL PROTECTED]> wrote:
On 7/3/06, James Dickens <[EMAIL PROTECTED]> wrote:> On 7/3/06,
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:> >> > >>> > >> Currently, I'm using executable maps to create zfs
> > >> home directories.> > >>> > >> Casper> > >> > >> > >Casper, anything you can share with us on that? Sounds interesting.> >
> >> > It's really very lame:> >> >> > Add to /etc/auto_home as last entry:> >> > +/etc/auto_home_import> >> > And install /etc/auto_home_import as executable script:
> >> > #!/bin/ksh -p> > #> > # Find home directory; create directories under /export/home> > # with zfs if they do not exist.> > #> >> > hdir=$(echo ~$1)
> >> > if [[ "$hdir" != /home/* ]]> > then> > # Not a user with a valid home directory.> > exit> > fi> >> > #> > # At this point we have verified that "$1" is a valid
> > # user with a home of the form /home/username.> > #> > h=/export/home/"$1"> > if [ -d "$h" ]> > then> > echo "localhost:$h"
> > exit 0> > fi> >> > /usr/sbin/zfs create "export/home/$1" || exit 1>> another way to do this that is quicker if you are executing this often> is create a user directory with all the skel files in place, snapshot
> it, then clone that directory and chown the files.>> zfs snapshot /export/home/[EMAIL PROTECTED] export/home/$1 ; chown -R /export/home/$1>oops i guess i need more coffeezfs clone /export/home/[EMAIL PROTECTED] export/home/$1 ; chown -R /export/home/$1
> James Dickens> uadmin.blogspot.com>>> >> > cd /etc/skel> > umask 022> > /bin/find . -type f | while read f; do
> > f=$(basename $f)> > # Remove optional local prefix /etc/skel files.> > f="$h/${f##local}"> > cp "$f" "$t"> > chown "$1" "$t"
> > done> >> > chown "$1" $h> >> > echo "localhost:$h"> > exit 0> >> > ___
> > zfs-discuss mailing list> > zfs-discuss@opensolaris.org> > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
> >>___zfs-discuss mailing listzfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Re: Re: Supporting ~10K users on ZFS
On 7/3/06, Nicholas Senedzuk <[EMAIL PROTECTED]> wrote:
I am new to zfs and do not understand the reason that you would want to
create a separate file system for each home directory. Can some one explain
to me why you would want to do this?
because in ZFS filesystems are cheap, you can assign a quota or
reservation for each user. you can see how much space they are using
with df /export/home/username or zfs list username no more waiting
for du -s to complete , you can make a snapshot of each users
data/filesystem.
I'm sure they are more but another time
James Dickens
uadmin.blogspot.com
On 7/3/06, James Dickens <[EMAIL PROTECTED]> wrote:
> On 7/3/06, James Dickens <[EMAIL PROTECTED]> wrote:
> > On 7/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >
> > > >>
> > > >> Currently, I'm using executable maps to create zfs
> > > >> home directories.
> > > >>
> > > >> Casper
> > > >
> > > >
> > > >Casper, anything you can share with us on that? Sounds interesting.
> > >
> > >
> > > It's really very lame:
> > >
> > >
> > > Add to /etc/auto_home as last entry:
> > >
> > > +/etc/auto_home_import
> > >
> > > And install /etc/auto_home_import as executable script:
> > >
> > > #!/bin/ksh -p
> > > #
> > > # Find home directory; create directories under /export/home
> > > # with zfs if they do not exist.
> > > #
> > >
> > > hdir=$(echo ~$1)
> > >
> > > if [[ "$hdir" != /home/* ]]
> > > then
> > > # Not a user with a valid home directory.
> > > exit
> > > fi
> > >
> > > #
> > > # At this point we have verified that "$1" is a valid
> > > # user with a home of the form /home/username.
> > > #
> > > h=/export/home/"$1"
> > > if [ -d "$h" ]
> > > then
> > > echo "localhost:$h"
> > > exit 0
> > > fi
> > >
> > > /usr/sbin/zfs create "export/home/$1" || exit 1
> >
> > another way to do this that is quicker if you are executing this often
> > is create a user directory with all the skel files in place, snapshot
> > it, then clone that directory and chown the files.
> >
> > zfs snapshot /export/home/[EMAIL PROTECTED] export/home/$1 ; chown -R
/export/home/$1
> >
> oops i guess i need more coffee
>
> zfs clone /export/home/[EMAIL PROTECTED] export/home/$1 ; chown -R
/export/home/$1
>
> > James Dickens
> > uadmin.blogspot.com
> >
> >
> > >
> > > cd /etc/skel
> > > umask 022
> > > /bin/find . -type f | while read f; do
> > > f=$(basename $f)
> > > # Remove optional local prefix /etc/skel files.
> > > f="$h/${f##local}"
> > > cp "$f" "$t"
> > > chown "$1" "$t"
> > > done
> > >
> > > chown "$1" $h
> > >
> > > echo "localhost:$h"
> > > exit 0
> > >
> > > ___
> > > zfs-discuss mailing list
> > > zfs-discuss@opensolaris.org
> > >
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
> > >
> >
> ___
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] [raidz] file not removed: No space left on device
That's excellent news, as with the frequency that customers applications go feral and write a whole heap of crap (or they don't watch closely enough with gradual filling) we will forever be getting calls if this functionality is *anything* but transparent... Most explorers I see have filesystem 100% full messages in them... It will be interesting to see how the current S10_u2 bits go. :) Nathan. On Tue, 2006-07-04 at 02:19, Eric Schrock wrote: > You don't need to grow the pool. You should always be able truncate the > file without consuming more space, provided you don't have snapshots. > Mark has a set of fixes in testing which do a much better job of > estimating space, allowing us to always unlink files in full pools > (provided there are no snapshots, of course). This provides much more > logical behavior by reserving some extra slop. > > - Eric > > On Mon, Jul 03, 2006 at 02:23:06PM +0200, Constantin Gonzalez wrote: > > Hi, > > > > of course, the reason for this is the copy-on-write approach: ZFS has > > to write new blocks first before the modification of the FS structure > > can reflect the state with the deleted blocks removed. > > > > The only way out of this is of course to grow the pool. Once ZFS learns > > how to free up vdevs this may become a better solution because you can then > > shrink the pool again after the rming. > > > > I expect many customers to run into similar problems and I've already gotten > > a number of "what if the pool is full" questions. My answer has always been > > "No file system should be used up more than 90% for a number of reasons", > > but > > in practice this is hard to ensure. > > > > Perhaps this is a good opportunity for an RFE: ZFS should reserve enough > > blocks in a pool in order to always be able to rm and destroy stuff. > > > > Best regards, > >Constantin > > > > P.S.: Most US Sun employees are on vacation this week, so don't be alarmed > > if the really good answers take some time :). > > -- > Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock > ___ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: what to put on zfs
Doug Scott wrote: It is likely that "best practice" will be to separate the root pool (that is, the pool where dataset are allocated) On a system with plenty of disks it is a good idea. I started doing this on my laptop, and later decided to combine root and data into one pool. The filesystem boundary gave me sufficent separation. Having separate pools made me have 2 partitions with fixed boundries, which limited ZFS's flexibility. For example, ISTR that pools can be exported, but individual filesystems within a pool cannot be exported separately from the pool in which they are located. -- -- Jeff VICTOR Sun Microsystemsjeff.victor @ sun.com OS AmbassadorSr. Technical Specialist Solaris 10 Zones FAQ:http://www.opensolaris.org/os/community/zones/faq -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS bug
Hi i found a bug its a bit hard to reproduce. # zfs create pool2/t1 # touch /pool2/t1/file # zfs snapshot pool2/[EMAIL PROTECTED] # zfs clone pool2/[EMAIL PROTECTED] pool2/t2 # zfs share pool2/t2 on a second box nfs mount the filesystem, same error if a solaris express box or linux # mount enterprise:/pool2/t2 /export/home/test # cd /export/home/test/ # cp .zfs/snapshot/snapshot/file . cp: .zfs/snapshot/snapshot/file and ./file are identical # echo "test test" >> file # cp .zfs/snapshot/snapshot/file . cp: .zfs/snapshot/snapshot/file and ./file are identical # this works as expected, or if done on the local system, if the file was not part of the clone. # uname -av SunOS enterprise 5.11 snv_39 sun4u sparc SUNW,Ultra-2 # James Dickens uadmin.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: Re: what to put on zfs
> Doug Scott wrote: > >>It is likely that "best practice" will be to > separate > >>the root pool (that is, the pool where dataset are > >>allocated) > > > > On a system with plenty of disks it is a good idea. > I started > > doing this on my laptop, and later decided to > combine root and > > data into one pool. The filesystem boundary gave me > sufficent > > separation. Having separate pools made me have 2 > partitions > > with fixed boundries, which limited ZFS's > flexibility. > > For example, ISTR that pools can be exported, but > individual filesystems within a > pool cannot be exported separately from the pool in > which they are located. That is correct, but on my laptop I have little need to export the pool. Since diskspace is a limited resource I prefer that I did not have fixed partitions, and let all filesystems be able to access the remaining space. I hit the a partition boundy the first time I cloned more root zfs filesystem, thus I changed to a single pool. I can still use 'zfs send' to copy any of the filesystems elsewhere. Doug This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Questions. (RAID-Z questions actually)
On Mon, Jul 03, 2006 at 11:13:33PM +0800, Steven Sim wrote: > Could someone elaborate more on the statement "metadata drives > reconstruction"... ZFS starts from the ubberblock and works its way down (think recursive tree traversal) the metadata to find all live blocks and rebuilds the replaced vdev's contents accordingly. No need to rebuild unused blocks. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
