Re: [zfs-discuss] Single SAN Lun presented to 4 Hosts
David Hopwood writes: > Note also that mounting a filesystem read-only does not guarantee that > the disk will not be written, because of atime updates (this is arguably > a Unix design flaw, but still has to be taken into account). So r may I can mount with the -noatime option. > I don't understand why you would ever want to risk this with valuable > data. Please don't create the impression that I suggested that, because other readers may believe you. I didn't suggest risking valuable data. I know about NFS, QFS, VCFS, and other reliable solutions. I asked my question out of technical curiosity, and I hereby apologize for the obvious waste of bandwith. In the future, I'll go look at the sources instead. Rainer ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Single SAN Lun presented to 4 Hosts
On 27/08/2007, at 12:36 AM, Rainer J.H. Brandt wrote: > Sorry, this is a bit off-topic, but anyway: > > Ronald Kuehn writes: >> No. You can neither access ZFS nor UFS in that way. Only one >> host can mount the file system at the same time (read/write or >> read-only doesn't matter here). > > I can see why you wouldn't recommend trying this with UFS > (only one host knows which data has been committed to the disk), > but is it really impossible? > > I don't see why multiple UFS mounts wouldn't work, if only one > of them has write access. Can you elaborate? Even with a single writer you would need to be concerned with read cache invalidation on the read-only hosts and (probably harder) ensuring that read hosts don't rely on half-written updates (since UFS doesn't do atomic on-disk updates). Even without explicit caching on the read-only hosts there is some "implicit caching" when, for example, a read host reads a directory entry and then uses that information to access a file. The file may have been unlinked in the meantime. This means that you need atomic reads, as well as writes. Boyd ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Is there _any_ suitable motherboard?
Ben Middleton wrote: > I've just purchased an Asus P5K WS, which seems to work OK. I had to download > the Marvell Yukon ethernet driver - but it's all working fine. It's also got > a PCI-X slot - so I have one of those Super Micro 8 port SATA cards - > providing a total of 16 SATA ports across the system. Other specs are one of > those Intel E6750 1333MHz FSB CPUs and 2Gb of matched memory. > > Looks like a classy board, single processor boards with PCI-X are a bit like hen's teeth. Ian ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Is there _any_ suitable motherboard?
For what it's worth, I bought a Gigabyte GA-M57SLI-S4 a couple of months ago and it rocks on a reasonably current Nevada. Certainly not the cheapest or most expensive, but I felt a good choice for multiple PCI-E slots and a couple of PCI slots. http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ClassValue=Motherboard&ProductID=2287&ProductName=GA-M57SLI-S4 Everything on it worked a treat for me, and paired with an Nvidia 7900GS, has handled pretty much whatever I have thrown at it, including Second Life on Solaris. :) On Nevada (at the time I build it, it was NV_65), everything just worked straight out of the box. Gig Ethernet, IDE ports, SATA ports (in compatability mode), USB, 1394, audio, dual core stuff, the lot. SATA ports work fine and dandy (up to about 70MB/S per port on the outer edge of the disk using Seagate 320GB 16MB cache 7200RPM disks) using the IDE emulation. I'm waiting for the build of nevada that provides the Nvidia MCP55 SATA controller support for native SATA stuff. Not long now... ZFS seems to be able to write down the channel's at about 80MB/s... (At least on a brand spanking new Zpool. Seems closer to 60MB/s now...) Once the Nvidia SATA stuff goes back, you'll have 6 ports of NVidia SATA goodness straight off the board. (and even now, you have 6 ports of reasonable speedyness in good old ATA mode.) From what I can tell, the Nvidia SATA devices hang straight off the PCI-E bus, so you might even be able to get 'em all running flat out. (Though, I'm basing this on the output of the prtconf, I could be completely wrong.) See bottom of post for the prtconf -D output. I'm also running it as a Solaris Xen Dom0 with other OS/s lurking on top of that, so the HVM support also works great. I have just submitted this board to the HCL for SXDE, and if I get a chance, I'll pull the latest S10 and give that a whirl too. Hope this helps. (and excuse the prtconf being from the Xen boot, rather than bare metal... got a bit of stuff happening on the box at the moment and did not feel like rebooting. ;) /root # prtconf -D System Configuration: Sun Microsystems i86pc Memory size: 3895 Megabytes System Peripherals (Software Nodes): i86xpv (driver name: rootnex) scsi_vhci, instance #0 (driver name: scsi_vhci) isa, instance #0 (driver name: isa) fdc, instance #0 (driver name: fdc) fd, instance #0 (driver name: fd) asy, instance #0 (driver name: asy) lp, instance #0 (driver name: ecpp) i8042, instance #0 (driver name: i8042) keyboard, instance #0 (driver name: kb8042) motherboard xpvd, instance #0 (driver name: xpvd) xencons, instance #0 (driver name: xencons) xenbus, instance #0 (driver name: xenbus) domcaps, instance #0 (driver name: domcaps) balloon, instance #0 (driver name: balloon) evtchn, instance #0 (driver name: evtchn) privcmd, instance #0 (driver name: privcmd) pci, instance #0 (driver name: npe) pci1458,5001 pci1458,c11 pci1458,c11 pci1458,c11 pci1458,5004, instance #0 (driver name: ohci) mouse, instance #1 (driver name: hid) pci1458,5004, instance #0 (driver name: ehci) pci-ide, instance #0 (driver name: pci-ide) ide, instance #0 (driver name: ata) sd, instance #1 (driver name: sd) sd, instance #0 (driver name: sd) ide (driver name: ata) pci-ide, instance #1 (driver name: pci-ide) ide, instance #2 (driver name: ata) cmdk, instance #0 (driver name: cmdk) ide, instance #3 (driver name: ata) cmdk, instance #1 (driver name: cmdk) pci-ide, instance #2 (driver name: pci-ide) ide (driver name: ata) ide (driver name: ata) pci-ide, instance #3 (driver name: pci-ide) ide (driver name: ata) ide (driver name: ata) pci10de,370, instance #0 (driver name: pci_pci) pci8086,1e, instance #0 (driver name: e1000g) pci1458,1000, instance #0 (driver name: hci1394) pci1458,a002, instance #0 (driver name: audiohd) pci1458,e000, instance #0 (driver name: nge) pci10de,377, instance #0 (driver name: pcie_pci) display, instance #0 (driver name: nvidia) pci1022,1100 (driver name: mc-amd) pci1022,1101 (driver name: mc-amd) pci1022,1102 (driver name: mc-amd) pci1022,1103, instance #0 (driver name: amd64_gart) iscsi, instance #0 (driver name: iscsi) pseudo, instance #0 (driver name: pseudo) options, instance #0 (driver name: options) agpgart, instance #0 (driver name: agpgart) xsvc, instance #0 (driver name: xsvc) used-resources cpus cpu, instance #0 cpu, instance #1 Nathan. Ben Middleton wrote: > I
[zfs-discuss] NV_65 AMD64 - ZFS seems to write fast and slow to a single spindle
Hey all - Just saw something really weird. I have been playing with by box for a little while now, and just noticed something whilst checking how fast / slow my IDE ports were on a newish motherboard... I had been copying around an image. Not a particularly large one - 500M ISO... I had been observing the read speed off disk, and write speed to disk. When reading from one disk and writing to another, I was seeing about 60MB/s and all was as expected. But, then, I thought I'd do one more run, and copied the *same* image as my last run... Of course, the image was in memory, so I expected there would be no reads and lots of writes. What I saw was lots of not very impressive speed (cmdk1 is the target): extended device statistics devicer/sw/s kr/s kw/s wait actv svc_t %w %b cmdk0 0.00.00.00.0 0.0 0.00.0 0 0 cmdk1 0.0 35.30.0 4514.1 32.4 2.0 975.3 100 100 extended device statistics devicer/sw/s kr/s kw/s wait actv svc_t %w %b cmdk0 0.00.00.00.0 0.0 0.00.0 0 0 cmdk1 0.0 36.70.0 4697.6 32.4 2.0 936.8 100 100 extended device statistics devicer/sw/s kr/s kw/s wait actv svc_t %w %b cmdk0 0.00.00.00.0 0.0 0.00.0 0 0 cmdk1 0.0 36.80.0 4650.6 32.4 2.0 935.1 100 100 extended device statistics devicer/sw/s kr/s kw/s wait actv svc_t %w %b cmdk0 0.00.00.00.0 0.1 0.00.0 0 0 cmdk1 0.0 37.50.0 4424.9 32.3 2.0 913.8 100 100 So my target disk, which is owned exclusively by ZFS, was apparently flat out writing at 4.4MB/s. At the time it goes bad, the svc_t jumps from about 125ms to 950ms. Ouch!! On closer inspection, I see that - - The cp returns almost immediately. (somewhat expected) - ZFS starts writing at about 60MB/s, but only for about 2 seconds (This is changable. Sometimes, it writes the whole image at the slower rate.) - the write rate drops back to 4 - 5MB/s - CPU usage is only 8% - I still have 1.5GB of 4GB free memory (Though I *am* running Xen at the moment. Not sure if that matters) - If I kick off a second copy to a different filename whilst the first is running it does not get any faster. - If I kick off a write to a raw zvol on the same pool, the write rate to the disk jumps back up to the expected 60MB/s, but drops again as soon as it's completed the write to the raw zvol... So, it seems it's not the disk itself. - The zpool *has* been exported and imported this boot. Not sure if that matters either. - I had a hunch that memory availability might be playing a part, so I forced a whole heap to be freed up with a honking big malloc and walk of the pages. I freed up 3GB (box has 4GB total) and it seems that I start to see the problem much more frequently as I get to about 1.5GB free. - It's not entirely predictable. Sometimes, it'll write at 50-60MB/s for up to 8 or so seconds, and others, it'll only write fast for a burst right at the start, then take quite some time to write out the rest. It's almost as if we are being throttled on the rate at which we can push data through the ZFS in-memory cache when writing previously read and written data. Or something equally bogus like me expecting that ZFS would write as fast as it can all the time, which I guess might be an invalid assumption? Now: This is running NV_65 with the Xen bits from back then. Not sure if that really matters. Does not seem that the disk is having problem - beaker:/disk2/crap # zpool status pool: disk2 state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM disk2 ONLINE 0 0 0 c3d0 ONLINE 0 0 0 errors: No known data errors pool: zfs state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM zfs ONLINE 0 0 0 c1d0s7ONLINE 0 0 0 errors: No known data errors c1d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0 Model: ST3320620AS Revision: Serial No: 6QF Size: 320.07GB <320070352896 bytes> Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0 Illegal Request: 0 c3d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0 Model: ST3320620AS Revision: Serial No: 6QF Size: 320.07GB <320070352896 bytes> Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0 Illegal Request: 0 c0t1d0 Soft Errors: 4 Hard Errors: 302 Transport Errors: 0 If anyone within SWAN on the ZFS team wanted to take a look at this box and see if it's a new bug or just me being a bonehead and not understanding what I'm seeing, please respond to me directly, and I can provide access. (I'll make an effort not to reboot the box just in case it's only this
Re: [zfs-discuss] Is there _any_ suitable motherboard?
I've just purchased an Asus P5K WS, which seems to work OK. I had to download the Marvell Yukon ethernet driver - but it's all working fine. It's also got a PCI-X slot - so I have one of those Super Micro 8 port SATA cards - providing a total of 16 SATA ports across the system. Other specs are one of those Intel E6750 1333MHz FSB CPUs and 2Gb of matched memory. Ben. 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] Single SAN Lun presented to 4 Hosts
Rainer J.H. Brandt wrote: > Ronald, > > thanks for your comments. > > I was thinking about this scenario: > > Host w continuously has a UFS mounted with read/write access. > Host w writes to the file f/ff/fff. > Host w ceases to touch anything under f. > Three hours later, host r mounts the file system read-only, > reads f/ff/fff, and unmounts the file system. > > My assumption was: > > a1) This scenario won't hurt w, > a2) this scenario won't damage the data on the file system, > a3) this scenario won't hurt r, and > a4) the read operation will succeed, > > even if w continues with arbitrary I/O, except that it doesn't > touch anything under f until after r has unmounted the file system. If the filesystem is mounted on host w, then host w is entitled to write to it at any time. If you want to reliably ensure that w does not perform any writes, then it must be unmounted on w. Note also that mounting a filesystem read-only does not guarantee that the disk will not be written, because of atime updates (this is arguably a Unix design flaw, but still has to be taken into account). So r may also write to the disk, unless the filesystem is specifically mounted with options that prevent any physical writes. > Of course everything that you and Tim and Casper said is true, > but I'm still inclined to try that scenario. I don't understand why you would ever want to risk this with valuable data. -- David Hopwood <[EMAIL PROTECTED]> ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Single SAN Lun presented to 4 Hosts
Rainer, If you are looking for a means to safely "READ" any filesystem, please take a look at Availability Suite. One can safely take Point-in-Time copies of any Solaris supported filesystem, including ZFS, at any snapshot interval of one's choosing, and then access the shadow volume on any system within the SAN, be it Fibre Channel or iSCSI. If the node wanting access to the data is distant, Available Suite also offers Remote Replication. http://www.opensolaris.org/os/project/avs/ http://www.opensolaris.org/os/project/iscsitgt/ Jim > Ronald, > > thanks for your comments. > > I was thinking about this scenario: > > Host w continuously has a UFS mounted with read/write access. > Host w writes to the file f/ff/fff. > Host w ceases to touch anything under f. > Three hours later, host r mounts the file system read-only, > reads f/ff/fff, and unmounts the file system. > > My assumption was: > > a1) This scenario won't hurt w, > a2) this scenario won't damage the data on the file system, > a3) this scenario won't hurt r, and > a4) the read operation will succeed, > > even if w continues with arbitrary I/O, except that it doesn't > touch anything under f until after r has unmounted the file system. > > Of course everything that you and Tim and Casper said is true, > but I'm still inclined to try that scenario. > > Rainer > ___ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss Jim Dunham Solaris, Storage Software Group Sun Microsystems, Inc. 1617 Southwood Drive Nashua, NH 03063 Email: [EMAIL PROTECTED] http://blogs.sun.com/avs ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Single SAN Lun presented to 4 Hosts
Rainer J.H. Brandt wrote: > Ronald, > > thanks for your comments. > > I was thinking about this scenario: > > Host w continuously has a UFS mounted with read/write access. > Host w writes to the file f/ff/fff. > Host w ceases to touch anything under f. > Three hours later, host r mounts the file system read-only, > reads f/ff/fff, and unmounts the file system. > > My assumption was: > > a1) This scenario won't hurt w, > a2) this scenario won't damage the data on the file system, > a3) this scenario won't hurt r, and > a4) the read operation will succeed, > > even if w continues with arbitrary I/O, except that it doesn't > touch anything under f until after r has unmounted the file system. > > Of course everything that you and Tim and Casper said is true, > but I'm still inclined to try that scenario. you might get lucky once (note: I said "might"), but there's no guarantee, and sooner or later this approach *will* cause data corruption. wouldn't it be much simpler to use NFS & automounter for this scenario (I didn't follow the whole thread, so this may have been discussed already)? Michael -- Michael SchusterSun Microsystems, Inc. recursion, n: see 'recursion' ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Single SAN Lun presented to 4 Hosts
Ronald, thanks for your comments. I was thinking about this scenario: Host w continuously has a UFS mounted with read/write access. Host w writes to the file f/ff/fff. Host w ceases to touch anything under f. Three hours later, host r mounts the file system read-only, reads f/ff/fff, and unmounts the file system. My assumption was: a1) This scenario won't hurt w, a2) this scenario won't damage the data on the file system, a3) this scenario won't hurt r, and a4) the read operation will succeed, even if w continues with arbitrary I/O, except that it doesn't touch anything under f until after r has unmounted the file system. Of course everything that you and Tim and Casper said is true, but I'm still inclined to try that scenario. Rainer ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Single SAN Lun presented to 4 Hosts
>Yes, thank you for confirming what I said. > >So it is possible, but not recommended, because I must take care >not to read from files for which buffers haven't been flushed yet. Not, it's much worse than that: UFS will not re-read cached data for the read-only mount so the read-only mount will continue to use data which is stale; e.g., once a file is opened and as long as its inode is in use (file open) or cached, you will never see a change to the file. You will never notice changes to data unless you no longer cache it. Panics and random data reads are guaranteed. Casper ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Single SAN Lun presented to 4 Hosts
On Sunday, August 26, 2007 at 17:47:32 CEST, Rainer J.H. Brandt wrote: > Ronald Kuehn writes: > > On Sunday, August 26, 2007 at 16:36:26 CEST, Rainer J.H. Brandt wrote: > > > > > Ronald Kuehn writes: > > > > No. You can neither access ZFS nor UFS in that way. Only one > > > > host can mount the file system at the same time (read/write or > > > > read-only doesn't matter here). > > > > > > I can see why you wouldn't recommend trying this with UFS > > > (only one host knows which data has been committed to the disk), > > > but is it really impossible? > > > > > > I don't see why multiple UFS mounts wouldn't work, if only one > > > of them has write access. Can you elaborate? > > > > Hi, > > > > UFS wasn't designed as a shared file system. The kernel > > always assumes it is the only party accessing or modifying > > any on-disk data structures. With that premise it uses caching > > quite heavily. The view of the file system (cached structures + on-disk > > state) is consistent. The on-disk state alone isn't while the > > file system is mounted. Any other system accessing the on-disk > > state w/o taking into consideration the data cached on the original > > host will probably see inconsistencies. This will lead to data corruption > > and panics. If only one system mounts the file system read/write > > and other hosts only mount it read-only the read-only hosts will > > get an inconsistent view of the file system because they don't know > > what's in the cache of the r/w host. > > > > These approaches exist to solve this problem: > > - Only allow one host to directly access the file system. Other > > systems access it by talking over the network to this host: > > + NFS > > + the pxfs layer of Sun Cluster (global file system) > > - Use a file system designed with some kind of co-ordination for parallel > > access to the on-disk data structures built in: > > + QFS (Shared mode uses a meta data server on one host to > > manage the right to access certain parts of the on-disk structures. > > The operation on the data itself then takes place over the storage > > path. In that case multiple systems can modify on-disk structures > > directly. They only need to ask the meta data server for permission.) > > > > I hope that helps, > > Ronald > > Yes, thank you for confirming what I said. > > So it is possible, but not recommended, because I must take care > not to read from files for which buffers haven't been flushed yet. It is technically possible to mount the file system on more than one system, but it _will_ lead to data corruption and panics. Just making sure buffers for a file have been flushed to disk on the writer is _not_ enough. So it is not only not recommended, it is practically not possible to do such a configuration in a safe way. There is no way to force the read-only host to only read the data when they are consistent. Even on a lower level, writes to the file system are not atomic. When the read-only host picks up data while the other hosts update is not complete it will get random inconsistencies instead of correct meta-data. So as a summary: No way to do that with current UFS. Ronald ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Single SAN Lun presented to 4 Hosts
Tim, thanks for answering... > > > > > > > ...but please don't send HTML, if possible. > > Try this explanation.. > > Host A mounts UFS file system rw > Hosts B-C mount sam UFS file system read only > > In natural scheme of things hosts B-C read files and cache > metadata about the files and file system. > > Host A changes the file system. The metadata that hosts B-C have cached > is now incorrect. If they go to access the file system and find that > its state has changed things can start to go wrong. Sure, that's why I said it wouldn't be recommended. But for someone who knows what he's doing, e.g. who reads from a transfer directory only after all writing to it is known to be completed, it should be technically possible, right? Thanks again, Rainer Brandt ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Single SAN Lun presented to 4 Hosts
Ronald Kuehn writes: > On Sunday, August 26, 2007 at 16:36:26 CEST, Rainer J.H. Brandt wrote: > > > Ronald Kuehn writes: > > > No. You can neither access ZFS nor UFS in that way. Only one > > > host can mount the file system at the same time (read/write or > > > read-only doesn't matter here). > > > > I can see why you wouldn't recommend trying this with UFS > > (only one host knows which data has been committed to the disk), > > but is it really impossible? > > > > I don't see why multiple UFS mounts wouldn't work, if only one > > of them has write access. Can you elaborate? > > Hi, > > UFS wasn't designed as a shared file system. The kernel > always assumes it is the only party accessing or modifying > any on-disk data structures. With that premise it uses caching > quite heavily. The view of the file system (cached structures + on-disk > state) is consistent. The on-disk state alone isn't while the > file system is mounted. Any other system accessing the on-disk > state w/o taking into consideration the data cached on the original > host will probably see inconsistencies. This will lead to data corruption > and panics. If only one system mounts the file system read/write > and other hosts only mount it read-only the read-only hosts will > get an inconsistent view of the file system because they don't know > what's in the cache of the r/w host. > > These approaches exist to solve this problem: > - Only allow one host to directly access the file system. Other > systems access it by talking over the network to this host: > + NFS > + the pxfs layer of Sun Cluster (global file system) > - Use a file system designed with some kind of co-ordination for parallel > access to the on-disk data structures built in: > + QFS (Shared mode uses a meta data server on one host to > manage the right to access certain parts of the on-disk structures. > The operation on the data itself then takes place over the storage > path. In that case multiple systems can modify on-disk structures > directly. They only need to ask the meta data server for permission.) > > I hope that helps, > Ronald Yes, thank you for confirming what I said. So it is possible, but not recommended, because I must take care not to read from files for which buffers haven't been flushed yet. Rainer Brandt ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Single SAN Lun presented to 4 Hosts
On Sunday, August 26, 2007 at 16:36:26 CEST, Rainer J.H. Brandt wrote: > Ronald Kuehn writes: > > No. You can neither access ZFS nor UFS in that way. Only one > > host can mount the file system at the same time (read/write or > > read-only doesn't matter here). > > I can see why you wouldn't recommend trying this with UFS > (only one host knows which data has been committed to the disk), > but is it really impossible? > > I don't see why multiple UFS mounts wouldn't work, if only one > of them has write access. Can you elaborate? Hi, UFS wasn't designed as a shared file system. The kernel always assumes it is the only party accessing or modifying any on-disk data structures. With that premise it uses caching quite heavily. The view of the file system (cached structures + on-disk state) is consistent. The on-disk state alone isn't while the file system is mounted. Any other system accessing the on-disk state w/o taking into consideration the data cached on the original host will probably see inconsistencies. This will lead to data corruption and panics. If only one system mounts the file system read/write and other hosts only mount it read-only the read-only hosts will get an inconsistent view of the file system because they don't know what's in the cache of the r/w host. These approaches exist to solve this problem: - Only allow one host to directly access the file system. Other systems access it by talking over the network to this host: + NFS + the pxfs layer of Sun Cluster (global file system) - Use a file system designed with some kind of co-ordination for parallel access to the on-disk data structures built in: + QFS (Shared mode uses a meta data server on one host to manage the right to access certain parts of the on-disk structures. The operation on the data itself then takes place over the storage path. In that case multiple systems can modify on-disk structures directly. They only need to ask the meta data server for permission.) I hope that helps, Ronald ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs raidz1+hopspare on X4500 ,can I ?
5x(8+1) raidz1 , 1 hot sapre 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] Single SAN Lun presented to 4 Hosts
Rainer Try this explanation.. Host A mounts UFS file system rw Hosts B-C mount sam UFS file system read only In natural scheme of things hosts B-C read files and cache metadata about the files and file system. Host A changes the file system. The metadata that hosts B-C have cached is now incorrect. If they go to access the file system and find that its state has changed things can start to go wrong. Global file systems like QFS have can have one writer and multiple readers as above and the readers can be configured to cache no metadata..or just cache is for a very short time...all is well. Global file systems can also have multiple readers and writers which require more complex mechanisms to maintain consistency. In the case of QFS that requires a server to own the file system metadata and all clients have to get information about the file system metadata from the metadata server. This is done over the network and the transfer the actual data blocks is done over the SAN. HTH Tim Rainer J.H. Brandt said the following : Sorry, this is a bit off-topic, but anyway: Ronald Kuehn writes: No. You can neither access ZFS nor UFS in that way. Only one host can mount the file system at the same time (read/write or read-only doesn't matter here). I can see why you wouldn't recommend trying this with UFS (only one host knows which data has been committed to the disk), but is it really impossible? I don't see why multiple UFS mounts wouldn't work, if only one of them has write access. Can you elaborate? Thanks, Rainer Brandt ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- Signature Tim Thomas Storage Systems Product Group Sun Microsystems, Inc. Internal Extension: x(70)18097 Office Direct Dial: +44-161-905-8097 Mobile: +44-7802-212-209 Email: [EMAIL PROTECTED] ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Single SAN Lun presented to 4 Hosts
Sorry, this is a bit off-topic, but anyway: Ronald Kuehn writes: > No. You can neither access ZFS nor UFS in that way. Only one > host can mount the file system at the same time (read/write or > read-only doesn't matter here). I can see why you wouldn't recommend trying this with UFS (only one host knows which data has been committed to the disk), but is it really impossible? I don't see why multiple UFS mounts wouldn't work, if only one of them has write access. Can you elaborate? Thanks, Rainer Brandt ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
