Re: [zfs-discuss] zfs diff cannot stat shares
On 10/13/10 10:20 AM, dirk schelfhout wrote: Wanted to test the zfs diff command and ran into this. I turned off all windows sharing. the rpool has normal permissions for .zfs/shares how do I fix this ? Dirk r...@osolpro:/data/.zfs# zfs diff d...@10aug2010 d...@13oct2010 Cannot stat /data/.zfs/shares/: unable to generate diffs pwd /data/.zfs r...@osolpro:/data/.zfs# ls -alt ls: cannot access shares: Operation not supported total 4 dr-xr-xr-x 2 rootroot 2 2010-10-13 17:44 snapshot drwxr-xr-x 18 piet staff 24 2010-10-13 17:44 .. dr-xr-xr-x 4 rootroot 4 2009-01-28 23:08 . What OS bits are you running? -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Making ZFS better: zfshistory
On 04/21/10 03:24 AM, Darren J Moffat wrote: On 21/04/2010 05:09, Edward Ned Harvey wrote: From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Nicolas Williams The .zfs/snapshot directory is most certainly available over NFS. I'm not sure you've been following this thread. Nobody said .zfs/snapshot wasn't available over NFS. It was said that all the snapshot subdirectories .zfs/snapshot/frequent-blah and .zfs/snapshot/hourly-foo and so on ... Over NFS there's no way to know the time those snapshots were taken. There is a convention of writing the time of the snapshot into the name of the snapshot, but if you can't rely on that, then the NFS client doesn't know the order of snapshots. Correct and think this is because POSIX has not such thing as a file creation date (ctime,mtime,atime is all it has) - ZFS actually does have a creation date but there isn't a way to expose that over NFS that I'm aware of and ls/stat can't see it because stat(2) doesn't have a way to expose it. You can see it with ls: # ls -ld -% all /net/server/export/ws/timh/nvc drwxr-xr-x 9 timh staff 13 Apr 21 01:25 /net/server/export/ws/timh/nvc/ timestamp: atime Apr 21 07:54:05 2010 timestamp: ctime Apr 21 01:25:48 2010 timestamp: mtime Apr 21 01:25:48 2010 timestamp: crtime Jun 22 08:27:23 2009 and I believe you can retrieve it with fgetattr() from the read/write view. -tim The snapshot dir is just another directory and over NFS you are looking at it with NFS so it shows the ctime,mtime,atime of the top level directory of the ZFS dataset at the time the snapshot was created. This RFE if it were to be implemented could give a possible way to get this information from a remote filesystem client: 6527390 want to read zfs properties over nfs (eg via .zfs/props) ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] [shell-discuss] getconf test for case insensitive ZFS?
On 04/14/10 11:48 AM, Glenn Fowler wrote: On Wed, 14 Apr 2010 17:54:02 +0200 =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= wrote: Can I use getconf to test if a ZFS file system is mounted in case insensitive mode? we would have to put in the zfs query (hopefull more generic that just for zfs) the only current working case-insensitive checks are for uwin ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss There is a pathconf(2) check described in the documentation for the case-insensitive behavior ARC case http://arc.opensolaris.org/caselog/PSARC/2007/244/spec.txt Not sure why it's not in the man page... -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] How to Catch ZFS error with syslog ?
On 04/12/10 09:05 AM, J James wrote: I have a simple mirror pool with 2 disks. I pulled out one disk to simulate a failed drive. zpool status shows that the pool is in DEGRADED state. I want syslog to log these type of ZFS errors. I have syslog running and logging all sorts of error to a log server. But this failed disk in ZFS pool did not generate any syslog messages. ZFS diagnosists engine are online as seen bleow. hrs1zgpprd1# fmadm config | grep zfs zfs-diagnosis 1.0 active ZFS Diagnosis Engine zfs-retire 1.0 active ZFS Retire Agent So, why is it not generating any syslog messages? Try explicitly enabling fmd to send to syslog in /usr/lib/fm/fmd/plugins/syslog-msgs.conf -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] how can I remove files when the fiile system is full?
On 04/ 1/10 01:46 PM, Eiji Ota wrote: During the IPS upgrade, the file system got full, then I cannot do anything to recover it. # df -kl Filesystem 1K-blocks Used Available Use% Mounted on rpool/ROOT/opensolaris 4976642 4976642 0 100% / swap 14217564 244 14217320 1% /etc/svc/volatile /usr/lib/libc/libc_hwcap2.so.1 4976642 4976642 0 100% /lib/libc.so.1 swap 14217460 140 14217320 1% /tmp swap 1421734424 14217320 1% /var/run # cd /var/adm # rm messages.? rm: cannot remove `messages.0': No space left on device rm: cannot remove `messages.1': No space left on device Likely a similar issue was reported a few years ago like: http://opensolaris.org/jive/thread.jspa?messageID=241580#241580 However, my system is on snv_133. Is there any way to work around the situation? This is really critical since after the IPS gets the file system full, customers seem not able to recover. Thanks, -Eiji ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss On opensolaris? Did you try deleting any old BEs? -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs diff
On 3/29/10 8:02 PM, Daniel Carosone wrote: On Tue, Mar 30, 2010 at 12:37:15PM +1100, Daniel Carosone wrote: There will also need to be clear rules on output ordering, with respect to renames, where multiple changes have happened to renamed files. Separately, but relevant in particular to the above due to the potential for races: what is the defined behaviour when diffing against a live filesystem (rather than a snapshot)? is there an implied snapshot (ie, diff based on content frozen at txg_id when started) or is thhe comparison done against a moving target? It's not just a question of implementation if it can affect the output, especially if it can make it internally inconsistent. -- Dan. Yes, a snapshot is taken and removed once the compare is performed. -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Recover rpool
On 03/ 9/10 10:53 AM, Cindy Swearingen wrote: Hi D, Is this a 32-bit system? We were looking at your panic messages and they seem to indicate a problem with memory and not necessarily a problem with the pool or the disk. Your previous zpool status output also indicates that the disk is okay. To perhaps clarify, you're panicking trying to grab a mutex, which hints that something has stomped on the memory containing that mutex. The reason for the 32-bit question is that sometimes a deep stack can overrun on a 32-bit box. That's probably not what happened here, but we ask anyway. -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] On collecting data from hangs
There seems to be a rash of posts lately where people are resetting or rebooting without getting any data, so I thought I'd post a quick overview on collecting crash dumps. If you think you've got a hang problem with ZFS and you want to gather data for someone to look at, then here are a few steps you should take. If you already know all about gathering crash dumps on Solaris, feel free to delete now. 1) Make sure crash dumps are enabled Enable saving of crash dumps by executing as root or with pfexec 'dumpadm -y'. The most reasonable trade-off of information vs size in the crash dump is probably 'dumpadm -c curproc' If you're running Opensolaris you likely already have a dedicated zvol as a dump device. If you're running SXCE you may need to dedicate a disk or slice for dump purposes. Change or dedicate the dump device with 'dumpadm -d device' See dumpadm(1M) for more info. 2) There are at least a couple of ways to capture crash dumps. As root or with pfexec run 'savecore -L'. This is a point-in-time capture of what's happening on the live system. The system continues to run during the capture so the results can be slightly inconsistent, but the machine won't reboot. Good if you think whatever is hung is still making progress. If you really don't mind rebooting, then 'reboot -nd' will most often get a dump without the dump also hanging up and forcing you to hard reset anyway. --- Number 1 is best done now, before you have a hang. It won't hurt anything to have crash dumps enabled - and if you ever get a panic you'll have the data needed for someone to analyze the issue. If the crash dump saving works, the default location for the dumps to be stored is the directory /var/crash/hostname. -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Quick dedup question
Rich Teer wrote: Congrats for integrating dedup! Quick question: in what build of Nevada will dedep first be found? b126 is the current one presently. Cheers, 128 -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] dedupe question
Dennis Clarke wrote: Does the dedupe functionality happen at the file level or a lower block level? block level, but remember that block size may vary from file to file. I am writing a large number of files that have the fol structure : -- file begins 1024 lines of random ASCII chars 64 chars long some tilde chars .. about 1000 of then some text ( english ) for 2K more text ( english ) for 700 bytes or so -- Each file has the same tilde chars and then english text at the end of 64K of random character data. Before writing the data I see : # zpool get size,capacity,version,dedupratio,free,allocated zp_dd NAME PROPERTYVALUESOURCE zp_dd size67.5G- zp_dd capacity6% - zp_dd version 21 default zp_dd dedupratio 1.16x- zp_dd free63.3G- zp_dd allocated 4.19G- After I see this : # zpool get size,capacity,version,dedupratio,free,allocated zp_dd NAME PROPERTYVALUESOURCE zp_dd size67.5G- zp_dd capacity6% - zp_dd version 21 default zp_dd dedupratio 1.11x- zp_dd free63.1G- zp_dd allocated 4.36G- Note the drop in dedup ratio from 1.16x to 1.11x which seems to indicate that dedupe does not detect the english text is identical in every file. Theory: Your files may end up being in one large 128K block or maybe a couple of 64K blocks where there isn't much redundancy to de-dup. -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS + fsck
Orvar Korvar wrote: Does this putback mean that I have to upgrade my zpool, or is it a zfs tool? If I missed upgrading my zpool I am smoked? The putback did not bump zpool or zfs versions. You shouldn't have to upgrade your pool. -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS + fsck
Robert Milkowski wrote: Miles Nordin wrote: csb == Craig S Bell cb...@standard.com writes: csb Two: If you lost data with another filesystem, you may have csb overlooked it and blamed the OS or the application, yeah, but with ZFS you often lose the whole pool in certain classes of repeatable real-world failures, like hotswap disks with flakey power or SAN's without NVRAM where the target reboots and the initiator does not. Losing the whole pool is relevantly different to corrupting the insides of a few files. I think that most people including ZFS developers agree with you that losing an access to entire pool is not acceptable. And this has been fixed in snv_126 so now in those rare circumstances you should be able to import a pool. And generally you will end-up in a much better situation than with legacy filesystems + fsck. Just a slight correction. The current build in-process is 128 and that's the build into which the changes were pushed. -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS + fsck
Robert Milkowski wrote: Kevin Walker wrote: Hi all, Just subscribed to the list after a debate on our helpdesk lead me to the posting about ZFS corruption and the need for a fsck repair tool of some kind... Has there been any update on this? I guess the discussion started after someone read an article on OSNEWS. The way zfs works is that basically you get an fsck equivalent while using a pool. ZFS checks checksums for all metadata and user data while reading it. Then all metadata are using ditto blocks to provide 2 or three copies of it (totally independent from any pool redundancy) depends on type of metadata. If it is corrupted a second (or third) copy will be used so correct data is returned and a corrupted block is automatically repaired. The ability to repair a block containing a user data depends on if you have a pool configured with or without redundancy. But even if pool is non-redundant (lets say a single disk drive) zfs still will be able to detect corruption and will be able to tell you what files are affected while metadata will be correct in most cases (unless corruption is so large and not localized so it affected all copies of a block in a pool). You will be able to read all other files and other parts of the file. So fsck actually happens while you are accessing your data and it is even better than fsck on most other filesystems as thanks to checksumming of all data and metadata zfs knows exactly when/if something is wrong and in most cases is even able to fix it on the fly. If you want to scan entire pool including all redundant copies and get them fix if something doesn't checksum then you can schedule the pool scrubbing (while your applications are still using the pool!). This will force zfs to read all blocks from all copies to be read, their checksum checked and if needed data corrected if possible and the fact reported to user. Legacy fsck is not even close to it. I think that the perceived need for fsck for ZFS probably comes from lack of understanding how ZFS works and from some frustrated users where under a very unlikely and rare circumstances due to data corruption a user might be in a position of not being able to import the pool therefore not being able to access any data at all while a corruption might have affected only a relatively small amount of data. Most other filesystem will allow you to access most of the data after fsck in such a situation (probably with some data loss) while zfs left user with no access to data at all. In such a case the problem lies with zfs uberblock and the remedy is to revert a pool to its previous uberblock version (or even an earlier one). In almost all the cases this will render a pool importable and then the mechanisms described in the first paragraph above will kick-in. The problem is (was) that the procedure to revert a pool to one of its previous uberblock is not documented nor is automatic and is definitely far from being sys-admin friendly. But thanks to some community members (most notably mr. Victor I think) some users affected by the issue were given a hand and were able to recover most/all their data. Others were probably assisted by Sun's support service I guess. Fortunately a much more user-friendly mechanism has been finally implemented and inegrated into Open Solaris build 126 which allows a user to import a pool and force it to on of the previous versions of its uberblock if necessary. See http://c0t0d0s0.org/archives/6067-PSARC-2009479-zpool-recovery-support.html for more details. There is another CR (don't have its number at hand) which is about implementing a delayed re-use on just freed blocks which should allow for more data to be recovered in such a case as above. Although I'm not sure if it has been implemented yet. IMHO with the above CR implemented, in most cases ZFS currently provides *much* better solution to random data corruption than any other filesystem+fsck in the market. The code for the putback of 2009/479 allows reverting to an earlier uberblock AND defers the re-use of blocks for a short time to make this rewind safer. -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] *Almost* empty ZFS filesystem - 14GB?
Chris Murray wrote: Accidentally posted the below earlier against ZFS Code, rather than ZFS Discuss. My ESXi box now uses ZFS filesystems which have been shared over NFS. Spotted something odd this afternoon - a filesystem which I thought didn't have any files in it, weighs in at 14GB. Before I start deleting the empty folders to see what happens, any ideas what's happened here? # zfs list | grep temp zp/nfs/esx_temp 14.0G 225G 14.0G /zp/nfs/esx_temp # ls -la /zp/nfs/esx_temp total 20 drwxr-xr-x 5 root root 5 Aug 13 12:54 . drwxr-xr-x 7 root root 7 Aug 13 12:40 .. drwxr-xr-x 2 root root 2 Aug 13 12:53 iguana drwxr-xr-x 2 root root 2 Aug 13 12:54 meerkat drwxr-xr-x 2 root root 2 Aug 16 19:39 panda # ls -la /zp/nfs/esx_temp/iguana/ total 8 drwxr-xr-x 2 root root 2 Aug 13 12:53 . drwxr-xr-x 5 root root 5 Aug 13 12:54 .. # ls -la /zp/nfs/esx_temp/meerkat/ total 8 drwxr-xr-x 2 root root 2 Aug 13 12:54 . drwxr-xr-x 5 root root 5 Aug 13 12:54 .. # ls -la /zp/nfs/esx_temp/panda/ total 8 drwxr-xr-x 2 root root 2 Aug 16 19:39 . drwxr-xr-x 5 root root 5 Aug 13 12:54 .. # Could there be something super-hidden, which I can't see here? There don't appear to be any snapshots relating to zp/nfs/esx_temp. On a suggestion, I have ran the following: # zfs list -r zp/nfs/esx_temp NAME USED AVAIL REFER MOUNTPOINT zp/nfs/esx_temp 14.0G 225G 14.0G /zp/nfs/esx_temp # du -sh /zp/nfs/esx_temp 8K /zp/nfs/esx_temp # Does zfs list -t snapshot -r zp/nfs/esx_temp show anything? What about zfs get refquota,refreservation,quota,reservation zp/fs/esx_tmp -tim Thanks, Chris ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs-discuss Digest, Vol 46, Issue 50
Allen Eastwood wrote: Does DNLC even play a part in ZFS, or are the Docs out of date? Defines the number of entries in the directory name look-up cache (DNLC). This parameter is used by UFS and NFS to cache elements of path names that have been resolved. No mention of ZFS. Noticed that when discussing that with a customer of mine. The best workload is one that doesn't read from disk to begin with :-) For workloads with millions of files (eg large-scale mail servers) you will need to increase the size of the Directory Name Lookup Cache (DNLC). By default, it is way too small for such workloads. If the directory names are in cache, then they do not have to be read from disk -- a big win. You can see how well the DNLC is working by looking at the output of vmstat -s and look for the total name lookups. You can size DNLC by tuning the ncsize parameter, but it requires a reboot. See the Solaris Tunable Parameters Guide for details. http://docs.sun.com/app/docs/doc/817-0404/chapter2-35?a=view Yes, ZFS uses the DNLC as well. -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] APPLE: ZFS need bug corrections instead of new func! Or?
Miles Nordin wrote: bmm == Bogdan M Maryniuk bogdan.maryn...@gmail.com writes: bmm OK, so what is the status of your bugreport about this? That's a good question if it's meant genuinely, and not to be obstructionist. It's hard to report one bug with clear information because the problem isn't well-isolated yet. In my notes: 6565042, 6749630 The first of which is marked as fixed in snv_77, 19 months ago. The second is marked as a duplicate of 6784395, fixed in snv_107, 20 weeks ago. -tim but as I said before, I've found the information on the mailing list more useful w.r.t. this particular problem. You can see how those bugs are about specific, methodically-reproduceable problems. Bugs are not ``I have been losing more zpools than I lost UFS/vxfs filesystems on top of the same storage platform.'' It may take a while. ___ 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] ZFS snapshot send/recv hangs X4540 servers
Brent Jones wrote: On Mon, Jun 8, 2009 at 9:38 PM, Richard Lowerichl...@richlowe.net wrote: Brent Jones br...@servuhome.net writes: I've had similar issues with similar traces. I think you're waiting on a transaction that's never going to come. I thought at the time that I was hitting: CR 6367701 hang because tx_state_t is inconsistent But given the rash of reports here, it seems perhaps this is something different. I, like you, hit it when sending snapshots, it seems (in my case) to be specific to incremental streams, rather than full streams, I can send seemingly any number of full streams, but incremental sends via send -i, or send -R of datasets with multiple snapshots, will get into a state like that above. -- Rich For now, back to snv_106 (the most stable build that I've seen, like it a lot) I'll open a case in the morning, and see what they suggest. After examining the dump we got from you (thanks again), we're relatively sure you are hitting 6826836 Deadlock possible in dmu_object_reclaim() This was introduced in nv_111 and fixed in nv_113. Sorry for the trouble. -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS snapshot send/recv hangs X4540 servers
Brent Jones wrote: Hello all, I had been running snv_106 for about 3 or 4 months on a pair of X4540's. I would ship snapshots from the primary server to the secondary server nightly, which was working really well. However, I have upgraded to 2009.06, and my replication scripts appear to hang when performing zfs send/recv. When one zfs send/recv process hangs, you cannot send any other snapshots from any other filesystem to the remote host. I have about 20 file systems I snapshots and replicate nightly. The script I use to perform the snapshots is here: http://www.brentrjones.com/wp-content/uploads/2009/03/replicate.ksh On the remote side, I end up with many hung processes, like this: bjones 11676 11661 0 01:30:03 ? 0:00 /sbin/zfs recv -vFd pdxfilu02 bjones 11673 11660 0 01:30:03 ? 0:00 /sbin/zfs recv -vFd pdxfilu02 bjones 11664 11653 0 01:30:03 ? 0:00 /sbin/zfs recv -vFd pdxfilu02 bjones 13727 13722 0 14:21:20 ? 0:00 /sbin/zfs recv -vFd pdxfilu02 And so on, one for each file system. On the receiving end, 'zfs list' shows one filesystem attempting to receive a snapshot, but I cannot stop it: $ zfs list NAME USED AVAIL REFER MOUNTPOINT pdxfilu02/data/fs01/%20090605-00:30:00 1.74G 27.2T 208G /pdxfilu02/data/fs01/%20090605-00:30:00 On the sending side, I CAN kill the ZFS send process, but the remote side leaves its processes going, and I CANNOT kill -9 them. I also cannot reboot the receiving system, at init 6, the system will just hang trying to unmount the file systems. I have to physically cut power to the server, but a couple days later, this issue will occur again. A crash dump from the receiving server with the stuck receives would be highly useful, if you can get it. Reboot -d would be best, but it might just hang. You can try savecore -L. -tim I'f I boot to my snv_106 BE, everything works fine, this issue has never occurred on that version. Any thoughts? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs related google summer of code ideas - your vote
Dave wrote: C. Bergström wrote: Bob Friesenhahn wrote: I don't know if anyone has noticed that the topic is google summer of code. There is only so much that a starving college student can accomplish from a dead-start in 1-1/2 months. The ZFS equivalent of eliminating world hunger is not among the tasks which may be reasonably accomplished, yet tasks at this level of effort is all that I have seen mentioned here. May I interject a bit.. I'm silently collecting this task list and even outside of gsoc may help try to arrange it from a community perspective. Of course this will be volunteer based unless /we/ get a sponsor or sun beats /us/ to it. So all the crazy ideas welcome.. I would really like to see a feature like 'zfs diff f...@snap1 f...@othersnap' that would report the paths of files that have either been added, deleted, or changed between snapshots. If this could be done at the ZFS level instead of the application level it would be very cool. -- Dave ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss this is actually in the works. There is a functioning prototype. -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] possibly a stupid question, why can I not set sharenfs=sec=krb5, rw?
Alastair Neil wrote: x86 snv 108 I have a pool with around 5300 file systems called home. I can do: zfs set sharenfs=on home however zfs set sharenfs=sec=krb5,rw home complains: cannot set property for 'home': 'sharenfs' cannot be set to invalid options I feel I must be overlooking something elementary. Thanks, Alastair ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss Does a by-hand share succeed? I.e, share -F nfs -o sec=krb5,rw /home ? -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS upgrade mangled my share
Colin Johnson wrote: I was having CIFs problems on my Mac so I upgrade to build 105. After getting all my shares populated with data I ran zpool scrub on the raidz array and it told me the version was out of date so I upgraded. One of my shares is now inaccessible and I cannot even delete it :( r...@bitchko:/nas1/backups# zfs list -r /nas1/backups/ NAME USED AVAIL REFER MOUNTPOINT nas1/backups 33.3K 1.04T 33.3K /nas1/backups r...@bitchko:/# zfs destroy /nas1/backups/ cannot open '/nas1/backups/': invalid dataset name There's a typo there, you would have to do zfs destroy nas1/backups Unfortunately, you can't use the mountpoint, you have to name the dataset. -tim r...@bitchko:/nas1# rm -Rf backups/ rm: cannot remove directory `backups/': Device busy This is pretty scary for something that's storing valuable data. Any ideas how I can destroy the dataset and recreate it? Thanks Colin ___ 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] ZFS encryption?? - [Fwd: [osol-announce] SXCE Build 105 available
Jerry K wrote: It was rumored that Nevada build 105 would have ZFS encrypted file systems integrated into the main source. In reviewing the Change logs (URL's below) I did not see anything mentioned that this had come to pass. Its going to be another week before I have a chance to play with b105. Does anyone know specifically if b105 has ZFS encryption? It does not. -tim Thanks, Jerry Original Message Subject: [osol-announce] SXCE Build 105 available Date: Fri, 09 Jan 2009 08:58:40 -0800 Please find the links to SXCE Build 105 at: http://www.opensolaris.org/os/downloads/ This is still a DVD only release. - wget work around: http://wikis.sun.com/pages/viewpage.action?pageId=28448383 --- Changelogs: ON (The kernel, drivers, and core utilities): http://dlc.sun.com/osol/on/downloads/b105/on-changelog-b105.html X Window System: http://opensolaris.org/os/community/x_win/changelogs/changelogs-nv_100/ - Derek ___ opensolaris-announce mailing list opensolaris-annou...@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-announce ___ 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] Changing casesensitivity for existing filesystems?
Nicolas Williams wrote: On Wed, Dec 10, 2008 at 11:13:21AM -0800, Jay Anderson wrote: The casesensitivity option is just like utf8only and normalization, it can only be set at creation time. The result from attempting to change it on an existing filesystem: # zfs set casesensitivity=mixed pool0/data1 cannot set property for 'pool0/data1': 'casesensitivity' is readonly From the ZFS Administration Guide (http://docs.sun.com/app/docs/doc/817-2271/6mhupg6lc?a=view#indexterm-319): The manpage I looked at didn't mention that, though it did for normalization and utf8only, so I foolishly stopped there. Sounds like a manpage bug. My apologies for the confusion. The manpage reads: The following three properties cannot be changed after the file system is created, and therefore, should be set when the file system is created. If the properties are not set with the zfs create or zpool create commands, these pro- perties are inherited from the parent dataset. If the parent dataset lacks these properties due to having been created prior to these features being supported, the new file system will have the default values for these properties. casesensitivity = sensitive | insensitive | mixed ... normalization =none | formD | formKCf ... utf8only =on | off ... We reiterate that the property cannot be changed in the paragraphs describing the second two, perhaps we should do so for the first as well. I would think only the casesensitivity=mixed should have to be set at creation time, that casesensitivity=insensitive could be set at any time. Hmmm. We don't allow this for a couple of reasons. If the file system was case-sensitive or mixed and you suddenly make it insensitive, you potentially create name conflicts: % ls Readme README readme if we make this case-insensitive all of sudden you've got two files that can no longer be looked up. The other reason is performance. Knowing beforehand that we need to track or disallow case conflicts helps us to optimize to keep lookups fast. -tim Nico ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] cp: Operation not supported
Kristof Van Damme wrote: Hi Tim, Thanks for having a look. The 'utf8only' setting is set to off. Important bit of additional information: We only seem to have this problem when copying to a zfs filesystem with the casesensitivity=mixed property. We need this because the filesystem will eventually be shared over NFS and CIFS. I attached a file with the relevant zfs properties of the filesystem that has the problem. See zfs-prop.txt. Notice that utf8only is set to off. My locale is set to en_US.ISO8859-15 when doing the copy, but that doesn't seem to change anything. I tried with en_US.UTF-8 as well with the same result. A truss on the failed can be found in truss-ENOTSUP.txt. Notice the \xf6 in the filename of the stat64, which gives an ENOTSUP. When we take an the UTF-8 name, the stat64 succeeds just fine. A truss of this can be found in truss-OK.txt Cheers, Kristof/ Kristof, Your detailed information was very helpful. I have reproduced the problem on my own machine. I will need to consult with our i18n folks on whether the problem is within zfs or one of their routines we are calling. -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] cp: Operation not supported
Kristof Van Damme wrote: Hi Tim, That's splendid! In case other people want to reproduce the issue themselves, here is how. In attach is a tar which contains the 2 files (UTF8 and ISO8859) like the ones I used in my first post to demonstrate the problem. Here are the instructions to reproduce the issue: Create a zfs filesystem with casesensitivity set to mixed and create one without this setting. Unpack the tar outside the pool and try to copy both the files from the tar on to the zfs fileystem. One (UTF8) will work fine, the other will not. # zfs create -o casesensitivity=mixed mypool/mixed # zfs create mypool/normal # cp UTF8-Köln.txt /mypool/mixed/ # cp ISO8859-K?ln.txt /mypool/mixed/ cp: cannot stat `/mypool/mixed/ISO8859-K\366ln.txt': Operation not supported # cp UTF8-Köln.txt /mypool/normal/ # cp ISO8859-K?ln.txt /mypool/normal/ # Kristof/ Thanks, Kristof I filed 6783995 file creation sometimes failing within a zfs where casesensitivity=mixed a short while ago. I believe I already have a fix: chinook:~/bugs/nonutf[1016] ls ISO8859-K?ln.txt* UTF8-Köln.txt koeln.tar chinook:~/bugs/nonutf[1016] zfs get casesensitivity tp/timh/mix NAME PROPERTY VALUESOURCE tp/timh/mix casesensitivity mixed- chinook:~/bugs/nonutf[1017] cp UTF8-K\303\266ln.txt /tp/timh/mix chinook:~/bugs/nonutf[1019] cp ISO8859-K\366ln.txt /tp/timh/mix chinook:~/bugs/nonutf[1021] ls /tp/timh/mix ISO8859-K?ln.txt* UTF8-Köln.txt Still will need some folks to look at the change, though. -tim ___ 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] cp: Operation not supported
Kristof Van Damme wrote: Hi All, We have set up a zpool on OpenSolaris 2008.11, but have difficulties copying files with special chars in the name when the name is encoded in ISO8859-15. When the name is in UTF8 we don't have this problem. We get Operation not supported. We want to copy the files with their name in ISO8859-15 encoding and do not want to convert them to UTF8, because we think this will cause it problems further down the road: The filesystem will be used as a network share (CIFS and NFS) for windows and linux clients. The clients may not all properly support UTF8 at the moment. So we'd like to avoid having to convert to UTF8 at this moment. How can we copy files with an ISO8859-encoded name? To demonstrate the problem: # /usr/bin/cp ISO8859-K?ln.url /datapool/appl cp: cannot create /datapool/appl/ISO8859-K?ln.url: Operation not supported # /usr/bin/cp UTF8-Köln.txt /datapool/appl/ # Kristof/ What is the output from: zfs get utf8only datapool/appl ? thanks, -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs is a co-dependent parent and won't let children leave home
Ross wrote: While it's good that this is at least possible, that looks horribly complicated to me. Does anybody know if there's any work being done on making it easy to remove obsolete boot environments? If the clones were promoted at the time of their creation the BEs would stay independent and individually deletable. Promotes can fail, though, if there is not enough space. I was told a little while back when I ran into this myself on an Nevada build where ludelete failed, that beadm *did* promote clones. This thread appears to be evidence to the contrary. I think it's a bug, we should either promote immediately on creation, or perhaps beadm destroy could do the promotion behind the covers. -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs is a co-dependent parent and won't let children leave home
Kyle McDonald wrote: Tim Haley wrote: Ross wrote: While it's good that this is at least possible, that looks horribly complicated to me. Does anybody know if there's any work being done on making it easy to remove obsolete boot environments? If the clones were promoted at the time of their creation the BEs would stay independent and individually deletable. Promotes can fail, though, if there is not enough space. I was told a little while back when I ran into this myself on an Nevada build where ludelete failed, that beadm *did* promote clones. This thread appears to be evidence to the contrary. I think it's a bug, we should either promote immediately on creation, or perhaps beadm destroy could do the promotion behind the covers. If I understand this right, the latter option looks better to me. Why consume the disk space before you have to? What does LU do? ludelete doesn't handle this any better than beadm destroy does, it fails for the same reasons. lucreate does not promote the clone it creates when a new BE is spawned, either. -tim -Kyle -tim ___ 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] problems accessing ZFS snapshots
Thomas Nau wrote: Dear all. I stumbled over an issue triggered by Samba while accessing ZFS snapshots. As soon as a Windows client tries to open the .zfs/snapshot folder it issues the Microsoft equivalent of ls dir, dir *. It get's translates by Samba all the way down into stat64(/pool/.zfs/snapshot*). The stat() call fails with error EILSEQ (Illegal byte sequence). It can easily reproduced by mybox# /bin/ls /pool/.zfs/snapshot/\* *: Illegal byte sequence Doing the same on the original ZFS the snapshot was taken from everything works fine. BTW, I'm running snv_93. Any hints on that? Thomas - GPG fingerprint: B1 EE D2 39 2C 82 26 DA A5 4D E0 50 35 75 9E ED ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss Interesting. What are the normalization and utf8only property values for the ZFS file system? I.e., what's the output from 'zfs get normalization,utf8only pool/fs' -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] problems accessing ZFS snapshots
Thomas Nau wrote: Dear all. I stumbled over an issue triggered by Samba while accessing ZFS snapshots. As soon as a Windows client tries to open the .zfs/snapshot folder it issues the Microsoft equivalent of ls dir, dir *. It get's translates by Samba all the way down into stat64(/pool/.zfs/snapshot*). The stat() call fails with error EILSEQ (Illegal byte sequence). It can easily reproduced by mybox# /bin/ls /pool/.zfs/snapshot/\* *: Illegal byte sequence Doing the same on the original ZFS the snapshot was taken from everything works fine. BTW, I'm running snv_93. Any hints on that? Thomas - GPG fingerprint: B1 EE D2 39 2C 82 26 DA A5 4D E0 50 35 75 9E ED ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss Ah, ignore my previous question. We believe we found the problem, and filed: 6731778 'ls *' in empty zfs snapshot directory returns EILSEQ vs. ENOENT we get in other empty directories Fix will likely go back today or tomorrow and be present in snv_96. Thanks for finding this. -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Creating root FS with mixed case sensitivity?
Aaron Moore wrote: Hello, I am trying to create a file server that will be used across multiple OSs and I wanted to create the root pool/zfs system with mixed case. I am not sure how to do this since the root zfs fs gets automatically created without this flag when I create the pool. Is there a way to do this? Thanks This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss Not just yet, unfortunately, but we are working on it. This is bug 6647661. http://www.opensolaris.org/isearch.jspa;jsessionid=F5B8A30AE9981256C1DE4F37EC7B72E1?query=6647661Submit=Search -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Solaris 10 x86 + ZFS / NFS server cp problem with AIX
Sachin Palav wrote: Friends, I have recently built a file server on x2200 with solaris x86 having zfs (version4) and running NFS version2 samba. the AIX 5.2 AIX 5.2 client give error while running command cp -R zfs_nfs_mount_source zfs_nfs_mount_desticantion as below: cp: 0653-440 directory/1: name too long. cp: 0653-438 cannot read directory directory/1. and the cp core dumps in AIX. Can someone please help This is almost certainly an instance of 6538383 in our bug database. scandir() is indeed broken on AIX, this is not a ZFS bug. If you have IBM support, you need to file something called a PMR with them to get the ball rolling on a fix. It's possible someone at Sun opened one already, I'm not certain. The workaround is to use a program that doesn't rely on scandir() to do the copying, tar or cpio as previously mentioned. Adding the -p option to cp appeared to be a workaround at one point, but that was a red herring, the failure with cp can be intermittent as it involves scandir() scribbling somewhat randomly over memory. -tim Thanks Sachin Palav This message posted from opensolaris.org ___ 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] path-name encodings
Roland Mainz wrote: Bart Smaalders wrote: Marcus Sundman wrote: I'm unable to find more info about this. E.g., what does reject file names mean in practice? E.g., if a program tries to create a file using an utf8-incompatible filename, what happens? Does the fopen() fail? Would this normally be a problem? E.g., do tar and similar programs convert utf8-incompatible filenames to utf8 upon extraction if my locale (or wherever the fs encoding is taken from) is set to use utf-8? If they don't, then what happens with archives containing utf8-incompatible filenames? Note that the normal ZFS behavior is exactly what you'd expect: you get the filenames you wanted; the same ones back you put in. Does ZFS convert the strings to UTF-8 in this case or will it just store the multibyte sequence unmodified ? ZFS doesn't muck with names it is sent when storing them on-disk. The on-disk name is exactly the sequence of bytes provided to the open(), creat(), etc. If normalization options are chosen, it may do some manipulation of the byte strings *when comparing* names, but the on-disk name should be untouched from what the user requested. -tim Bye, Roland ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Can't remove corrupt file
On Wed, 19 Jul 2006, Eric Lowe wrote: (Also BTW that page has a typo, you might want to get the typo fixed, I didn't know where the doc bugs should go for those messages) - Eric Product: event_registry Category: events Sub-Category: msg -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
