Re: [zfs-discuss] snapdir visable recursively throughout a dataset
Ben Rockwood wrote: Robert Milkowski wrote: I haven't tried it but what if you mounted ro via loopback into a zone /zones/myzone01/root/.zfs is loop mounted in RO to /zones/myzone01/.zfs That is so wrong. ;) Besides just being evil, I doubt it'd work. And if it does, it probly shouldn't. I think I'm the only one that gets a rash when using LOFI. lofi or lofs ? lofi - Loopback file driver Makes a block device from a file lofs - loopback virtual file system Makes a file system from a file system -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] snapdir visable recursively throughout a dataset
Darren J Moffat wrote: Ben Rockwood wrote: Robert Milkowski wrote: I haven't tried it but what if you mounted ro via loopback into a zone /zones/myzone01/root/.zfs is loop mounted in RO to /zones/myzone01/.zfs That is so wrong. ;) Besides just being evil, I doubt it'd work. And if it does, it probly shouldn't. I think I'm the only one that gets a rash when using LOFI. lofi or lofs ? lofi - Loopback file driver Makes a block device from a file lofs - loopback virtual file system Makes a file system from a file system Yes, I know. I was referring more so to loopback happy people in general. :) benr. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re[2]: [zfs-discuss] snapdir visable recursively throughout a dataset
Hello Ben, Tuesday, February 6, 2007, 10:19:54 AM, you wrote: BR> Darren J Moffat wrote: >> Ben Rockwood wrote: >>> Robert Milkowski wrote: I haven't tried it but what if you mounted ro via loopback into a zone /zones/myzone01/root/.zfs is loop mounted in RO to /zones/myzone01/.zfs >>> >>> That is so wrong. ;) >>> >>> Besides just being evil, I doubt it'd work. And if it does, it >>> probly shouldn't. I think I'm the only one that gets a rash when >>> using LOFI. >> >> lofi or lofs ? >> >> lofi - Loopback file driver >> Makes a block device from a file >> lofs - loopback virtual file system >> Makes a file system from a file system BR> Yes, I know. I was referring more so to loopback happy people in BR> general. :) What's wrong with it? Every sparse zone you've got in a system is using lofs anyway. -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] se3510 and ZFS
Hello zfs-discuss, It looks like when zfs issues write cache flush commands se3510 actually honors it. I do not have right now spare se3510 to be 100% sure but comparing nfs/zfs server with se3510 to another nfs/ufs server with se3510 with "Periodic Cache Flush Time" set to disable or so longer time I can see that cache utilization on nfs/ufs stays about 48% while on nfs/zfs it's hardly reaches 20% and every few seconds goes down to 0 (I guess every txg_time). nfs/zfs also has worse performance than nfs/ufs. Does anybody know how to tell se3510 not to honor write cache flush commands? -- Best regards, Robert mailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] se3510 and ZFS
Hello Robert, Tuesday, February 6, 2007, 12:55:19 PM, you wrote: RM> Hello zfs-discuss, RM> It looks like when zfs issues write cache flush commands se3510 RM> actually honors it. I do not have right now spare se3510 to be 100% RM> sure but comparing nfs/zfs server with se3510 to another nfs/ufs RM> server with se3510 with "Periodic Cache Flush Time" set to disable RM> or so longer time I can see that cache utilization on nfs/ufs stays RM> about 48% while on nfs/zfs it's hardly reaches 20% and every few RM> seconds goes down to 0 (I guess every txg_time). RM> nfs/zfs also has worse performance than nfs/ufs. RM> Does anybody know how to tell se3510 not to honor write cache flush RM> commands? Is there mdb hack to disable issuing write cache flushes by zfs? It could be better than disabling it on the array itself as less scsi commands would be send. -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] se3510 and ZFS
On Feb 6, 2007, at 06:55, Robert Milkowski wrote: Hello zfs-discuss, It looks like when zfs issues write cache flush commands se3510 actually honors it. I do not have right now spare se3510 to be 100% sure but comparing nfs/zfs server with se3510 to another nfs/ufs server with se3510 with "Periodic Cache Flush Time" set to disable or so longer time I can see that cache utilization on nfs/ufs stays about 48% while on nfs/zfs it's hardly reaches 20% and every few seconds goes down to 0 (I guess every txg_time). nfs/zfs also has worse performance than nfs/ufs. Does anybody know how to tell se3510 not to honor write cache flush commands? I don't think you can .. DKIOCFLUSHWRITECACHE *should* tell the array to flush the cache. Gauging from the amount of calls that zfs makes to this vs ufs (fsck, lockfs, mount?) - i think you'll see the performance diff, particularly when you hit an NFS COMMIT. (If you don't use vdevs you may see another difference in zfs as the only place you'll hit is on the zil) btw - you may already know, but you'll also fall to write-through on the cache if your battery charge drops and we also recommend setting to write- through when you only have a single controller since a power event could result in data loss. Of course there's a big performance difference between write-back and write-through cache --- .je ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re[2]: [zfs-discuss] se3510 and ZFS
Hello Jonathan, Tuesday, February 6, 2007, 5:00:07 PM, you wrote: JE> On Feb 6, 2007, at 06:55, Robert Milkowski wrote: >> Hello zfs-discuss, >> >> It looks like when zfs issues write cache flush commands se3510 >> actually honors it. I do not have right now spare se3510 to be 100% >> sure but comparing nfs/zfs server with se3510 to another nfs/ufs >> server with se3510 with "Periodic Cache Flush Time" set to disable >> or so longer time I can see that cache utilization on nfs/ufs stays >> about 48% while on nfs/zfs it's hardly reaches 20% and every few >> seconds goes down to 0 (I guess every txg_time). >> >> nfs/zfs also has worse performance than nfs/ufs. >> >> Does anybody know how to tell se3510 not to honor write cache flush >> commands? JE> I don't think you can .. DKIOCFLUSHWRITECACHE *should* tell the array JE> to flush the cache. Gauging from the amount of calls that zfs makes to JE> this vs ufs (fsck, lockfs, mount?) - i think you'll see the JE> performance diff, JE> particularly when you hit an NFS COMMIT. (If you don't use vdevs you JE> may see another difference in zfs as the only place you'll hit is on JE> the zil) IMHO it definitely shouldn't actually. The array has two controllers and write cache is mirrored. Also this is not the only host using that array. You can actually win much of a performance, especially with nfs/zfs setup (lot of synchronous ops) I guess. IIRC Bill posted here some tie ago saying the problem with write cache on the arrays is being worked on. JE> btw - you may already know, but you'll also fall to write-through on JE> the cache JE> if your battery charge drops and we also recommend setting to write- JE> through JE> when you only have a single controller since a power event could JE> result in JE> data loss. Of course there's a big performance difference between JE> write-back and write-through cache I can understand reduced performance with one controller (however I can force write-back on se3510 even with one controller - depending on situation we can argue if it would be wise or not) however until write cache is protected I definitely do not want ZFS to issue DKIOCFLUSHWRITECACHE. Ideally ZFS could figure out itself with recognized arrays. But I would like to be able to set it my self on pool basis anyway (there're always specific situations). -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [storage-discuss] Re[2]: [zfs-discuss] se3510 and ZFS
IIRC Bill posted here some tie ago saying the problem with write cache on the arrays is being worked on. Yep, the bug is: 6462690 sd driver should set SYNC_NV bit when issuing SYNCHRONIZE CACHE to SBC-2 devices We have a case going through PSARC that will make things works correctly with regards to flushing the write cache and non-volatile caches. The tricky part is getting vendors to actually support SYNC_NV bit. If you your favorite vendor/array doesn't support it, feel free to give them a call... eric ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: Re[2]: [zfs-discuss] se3510 and ZFS
On Feb 6, 2007, at 11:46, Robert Milkowski wrote: Does anybody know how to tell se3510 not to honor write cache flush commands? JE> I don't think you can .. DKIOCFLUSHWRITECACHE *should* tell the array JE> to flush the cache. Gauging from the amount of calls that zfs makes to JE> this vs ufs (fsck, lockfs, mount?) correction .. UFS uses _FIOFFS which is a file ioctl not a device ioctl which makes sense given the difference in models .. hence UFS doesn't care if the device write cache is turned on or off as it only makes dkio calls for geometry, info and such. you can poke through the code to see what other dkio ioctls are being made by z .. i believe it's due to the design of a closer tie between the underlying devices and the file system that there's a big difference. The DKIOCFLUSH PSARC is here: http://www.opensolaris.org/os/community/arc/caselog/2004/652/spec/ however I'm not sure if the 3510 maintains a difference between the entire array cache and the cache for a single LUN/device .. we'd have to dig up one of the firmware engineers for a more definitive answer. Point well taken on shared storage if we're flushing an array cache here :) --- .je ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] boot disks & controller layout...
ozan s. yigit wrote: not strictly a zfs question but related: after giving a lot of thought to the appropriate zpool layout in an x4500, we decided to use raidz2 5x(7+2)+1 layout, paying attention to having no more than two disks per set in each controller. in the process, i want to move my root mirror to another controller, say C6T0. is there any reason why factory install comes with C5T0 and C5T4? a limitation of the bios or some other reason i am missing? (i may need to RTFM harder... :) BIOS limitation. For a discussion on why you don't need to worry: http://blogs.sun.com/relling/entry/zfs_raid_recommendations_space_vs -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] boot disks & controller layout...
ah, good stuff. thanks. oz Richard Elling [in response to my question] wrote: ozan s. yigit wrote: ... is there any reason why factory install comes with C5T0 and C5T4? a limitation of the bios or some other reason i am missing? (i may need to RTFM harder... :) BIOS limitation. For a discussion on why you don't need to worry: http://blogs.sun.com/relling/entry/zfs_raid_recommendations_space_vs -- richard -- ozan s. yigit | [EMAIL PROTECTED] | o: 416-348-1540 if you want to have your head in the clouds you need to keep your feet on the ground. -- terry pratchett ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re[2]: [storage-discuss] Re[2]: [zfs-discuss] se3510 and ZFS
Hello eric, Tuesday, February 6, 2007, 5:55:23 PM, you wrote: >> >> IIRC Bill posted here some tie ago saying the problem with write cache >> on the arrays is being worked on. ek> Yep, the bug is: ek> 6462690 sd driver should set SYNC_NV bit when issuing SYNCHRONIZE ek> CACHE to ek> SBC-2 devices Thanks. I see a workaround there (I saw it earlier but it doesn't apply to 3510) and I have a question - setting zil_disable to 1 won't actually completely disable cache flushing, right? (still every txg group completes cache would be flushed)?? ek> We have a case going through PSARC that will make things works ek> correctly with regards to flushing the write cache and non-volatile ek> caches. There's actually a tunable to disable cache flushes: zfs_nocacheflush and in older code (like S10U3) it's zil_noflush. H... ek> The tricky part is getting vendors to actually support SYNC_NV bit. ek> If you your favorite vendor/array doesn't support it, feel free to ek> give them a call... Is there any work being done to ensure/check that all arrays Sun sells do support it? -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re[2]: [zfs-discuss] Re: ZFS volume is hosing BIOS POST on Ultra20 (BIOS 2.1.7)
Hello Casper, Monday, January 22, 2007, 2:56:16 PM, you wrote: >>Is there an BIOS uptade for Ultra20 to make it understand EFI? CDSC> Understanding EFI is perhaps asking too much; but I believe the CDSC> latest BIOS no longer hangs/crashes when it encountered EFI labels CDSC> on disks it examines. (All disks it probes) That's what we looked for. Somehow my friend missed that. Thank you. -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Meta data corruptions on ZFS.
Hi All, No one has any idea on this ? -Masthan dudekula mastan <[EMAIL PROTECTED]> wrote: Hi All, In my test set up, I have one zpool of size 1000M bytes. On this zpool, my application writes 100 files each of size 10 MB. First 96 files were written successfully with out any problem. But the 97 file is not written successfully , it written only 5 MB (the return value of write() call ). Since it is short write my application tried to truncate it to 5MB. But ftruncate is failing with an erroe message saying that No space on the devices. Have you people ever seen these kind of error message ? After ftruncate failure I checked the size of 97 th file, it is strange. The size is 7 MB but the expected size is only 5 MB. You help is appreciated. Thanks & Regards Mastan - TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV.___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss - Have a burning question? Go to Yahoo! Answers and get answers from real people who know.___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [storage-discuss] Re[2]: [zfs-discuss] se3510 and ZFS
Robert Milkowski wrote On 02/06/07 11:43,: Hello eric, Tuesday, February 6, 2007, 5:55:23 PM, you wrote: IIRC Bill posted here some tie ago saying the problem with write cache on the arrays is being worked on. ek> Yep, the bug is: ek> 6462690 sd driver should set SYNC_NV bit when issuing SYNCHRONIZE ek> CACHE to ek> SBC-2 devices Thanks. I see a workaround there (I saw it earlier but it doesn't apply to 3510) and I have a question - setting zil_disable to 1 won't actually completely disable cache flushing, right? (still every txg group completes cache would be flushed)?? ek> We have a case going through PSARC that will make things works ek> correctly with regards to flushing the write cache and non-volatile ek> caches. There's actually a tunable to disable cache flushes: zfs_nocacheflush and in older code (like S10U3) it's zil_noflush. Yes, but we didn't want to publicise this internal switch. (I would not call it a tunable). We (or at least I) are regretting publicising zil_disable, but using zfs_nocacheflush is worse. If the device is volatile then we can get pool corruption. An uberblock could get written before all of its tree. Note, zfs_nocacheflush and zil_noflush are not the same. Setting zil_noflush stopped zil flushes of the write cache, whereas zfs_nocacheflush will additionally stop flushing for txgs. H... ek> The tricky part is getting vendors to actually support SYNC_NV bit. ek> If you your favorite vendor/array doesn't support it, feel free to ek> give them a call... Is there any work being done to ensure/check that all arrays Sun sells do support it? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] The ZFS MOS and how DNODES are stored
ZFS documentation lists snapshot limits on any single file system in a pool at 2**48 snaps, and that seems to logically imply that a snap on a file system does not require an update to the pool’s currently active uberblock. That is to say, that if we take a snapshot of a file system in a pool, and then make any changes to that file system, the copy on write behavior induced by the changes will stop at some synchronization point below the uberblock (presumably at or below the DNODE that is the DSL directory for that file system). In-place updates to a DNODE that has been allocated in a single sector sized ZFS block can be considered atomic, since the sector write will either succeed or fail totally, leaving either the old version or the new version, but not a combination of the two. This seems sensible to me, but the description of object sets beginning on page 26 of the ZFS On-Disk Specification, states that the DNODE type DMU_OT_DNODE (the type of the DNODE that’s included in the 1KB objset_phys_t structure) will have a data load of an array of DNODES allocated in 128KB blocks, and the picture (Illustration 12 in the spec) shows these blocks as containing 1024 DNODES. Since DNODES are 512 bytes, it would not be possible to fit the 1024 DNODES depicted in the illustration and if DNODES did live in such an array then they could not be atomically updated in-place. If the blocks in question were actually filled with an array of block pointers pointing to single sector sized blocks that each held a DNODE then this would account for the 1024 entries per 128KB block shown, since block pointers are 128 bytes (not the 512 bytes of a DNODE), but in this case wouldn’t such 128KB blocks be considered to be indirect block pointers, forcing the dn_nlevels field shown in the object set DNODE at the top left of Illustration 12 to be 2, instead of the 1 that’s there ? I’m further confused by the illustration’s use of dotted lines to project the contents of a structure field (as seen in the projection of the metadnode field of the objset_phys_t structure found at the top of the picture) and arrows to represent pointers (as seen in the projection of the block pointer array of the DMU-OT-DNODE type dnode, also at the top of the picture), but the blocks pointed to by these block pointers seem to actually contain instances of DNODES (as seen from the projection of one of these instances in the lower part of the picture). Should this projection be replaced by a pointer to the lower DNODE ? This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: Re[2]: [storage-discuss] Re[2]: [zfs-discuss] se3510 and ZFS
On Feb 6, 2007, at 10:43 AM, Robert Milkowski wrote: Hello eric, Tuesday, February 6, 2007, 5:55:23 PM, you wrote: IIRC Bill posted here some tie ago saying the problem with write cache on the arrays is being worked on. ek> Yep, the bug is: ek> 6462690 sd driver should set SYNC_NV bit when issuing SYNCHRONIZE ek> CACHE to ek> SBC-2 devices Thanks. I see a workaround there (I saw it earlier but it doesn't apply to 3510) and I have a question - setting zil_disable to 1 won't actually completely disable cache flushing, right? (still every txg group completes cache would be flushed)?? Right, zil_disable is orthogonal to flushing the write cache. With or without the ZIL, ZFS is consistent on disk. Disabling the flushing of the write cache (as Neil just mentioned) *can cause corruption*. ek> The tricky part is getting vendors to actually support SYNC_NV bit. ek> If you your favorite vendor/array doesn't support it, feel free to ek> give them a call... Is there any work being done to ensure/check that all arrays Sun sells do support it? We're working it from our end, but i'm sure we won't cover all 3rd party vendors... eric ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: solaris - ata over ethernet - zfs - HPC
>We've considered looking at porting the AOE _server_ module to Solaris, >especially since the Solaris loopback driver (/dev/lofi) is _much_ more >stable than the loopback module in Linux (the Linux loopback module is a >stellar piece of crap). ok, it`s quite old and probably not the most elegant solution - but unstable? could you underline that somehow? i use the loopback module for years and never had a problem. anyway - it`s getting a competitor: bugfixed version of dm-loop device-mapper target has just been posted on dm-devel today. roland This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: solaris - ata over ethernet - zfs - HPC
Kevin Abbey wrote: Does this seem like a good idea? I am not a storage expert and am attempting to create a scalable distributed storage cluster for an HPC cluster. An AOE/ZFS/NFS setup doesn't sound scalable or distributed; your ZFS/NFS server may turn out to be a bottleneck. Wes Felter - [EMAIL PROTECTED] ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: Limit ZFS Memory Utilization
If I understand correctly, at least some systems claim not to guarantee consistency between changes to a file via write(2) and changes via mmap(2). But historically, at least in the case of regular files on local UFS, since Solaris used the page cache for both cases, the results should have been consistent. Since zfs uses somewhat different mechanisms, does it still have the same consistency between write(2) and mmap(2) that was historically present (whether or not "guaranteed") when using UFS on Solaris? 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] VxVM volumes in a zpool.
On 1/18/07, Tan Shao Yi <[EMAIL PROTECTED]> wrote: Hi, Was wondering if anyone had experience working with VxVM volumes in a zpool. We are using VxVM 5.0 on a Solaris 10 11/06 box. The volume is on a SAN, with two FC HBAs connected to a fabric. The setup works, but we observe a very strange message on bootup. The bootup screen is attached at the bottom of this e-mail. I suspect that the problem is that svc:/system/vxvm/vxvm-sysboot:default needs to be online before svc:/system/filesystem/local:default. I bet that adding something like the following to /var/svc/manifest/system/vxvm/vxvm-sysboot.xml: You can then run: svccfg import /var/svc/manifest/system/vxvm/vxvm-sysboot.xml On your next boot it should bring up (or try to...) vxconfigd (which should make volumes available) before the first zfs commands are run. I suspect that if /usr or /opt is a separate file system, you may have issues with this dependency. This is based upon 5 minutes of looking, not a careful read of all the parts involved. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Limit ZFS Memory Utilization
Richard, Richard L. Hamilton wrote: If I understand correctly, at least some systems claim not to guarantee consistency between changes to a file via write(2) and changes via mmap(2). But historically, at least in the case of regular files on local UFS, since Solaris used the page cache for both cases, the results should have been consistent. Since zfs uses somewhat different mechanisms, does it still have the same consistency between write(2) and mmap(2) that was historically present (whether or not "guaranteed") when using UFS on Solaris? Yes, it does have the consistency. There is specific code to keep the page cache (needed in case of mmaped files) and the ARC caches consistent. Thanks and regards, Sanjeev. -- Solaris Revenue Products Engineering, India Engineering Center, Sun Microsystems India Pvt Ltd. Tel:x27521 +91 80 669 27521 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Meta data corruptions on ZFS.
Masthan, */dudekula mastan <[EMAIL PROTECTED]>/* wrote: Hi All, In my test set up, I have one zpool of size 1000M bytes. Is this the size given by zfs list ? Or is the amount of disk space that you had ? The reason I ask this is because ZFS/Zpool takes up some amount of space for its house keeping. So, if you add 1G worth of disk space to the pool the effective space available is a little less (few MBs) than 1G. On this zpool, my application writes 100 files each of size 10 MB. First 96 files were written successfully with out any problem. Here you are filling the FS to the brim. This is a border case and the copy-on-write nature of ZFS could lead to the behaviour that you are seeing. But the 97 file is not written successfully , it written only 5 MB (the return value of write() call ). Since it is short write my application tried to truncate it to 5MB. But ftruncate is failing with an erroe message saying that No space on the devices. This is expected because of the copy-onwrite nature of ZFS. During truncate it is trying to allocate new disk blocks probably to write the new metadata and fails to find them. Have you people ever seen these kind of error message ? Yes, there are others who have seen these errors. After ftruncate failure I checked the size of 97 th file, it is strange. The size is 7 MB but the expected size is only 5 MB. Is there any particular reason that you are pushing the filesystem to the brim ? Is this part of some test ? Please, help us understand what you are trying to test. Thanks and regards, Sanjeev. -- Solaris Revenue Products Engineering, India Engineering Center, Sun Microsystems India Pvt Ltd. Tel:x27521 +91 80 669 27521 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
