Re: [zfs-discuss] Another user looses his pool (10TB) in this case and 40 days work

2009-07-26 Thread David Magda
On Jul 25, 2009, at 16:30, Carson Gaspar wrote: Frank Middleton wrote: Doesn't this mean /any/ hardware might have this problem, albeit with much lower probability? No. You'll lose unwritten data, but won't corrupt the pool, because the on-disk state will be sane, as long as your iSCSI

Re: [zfs-discuss] Another user looses his pool (10TB) in this case and 40 days work

2009-07-26 Thread David Magda
On Jul 25, 2009, at 15:32, Frank Middleton wrote: Can you comment on if/how mirroring or raidz mitigates this, or tree corruption in general? I have yet to lose a pool even on a machine with fairly pathological problems, but it is mirrored (and copies=2). Presumably at least on of the drives

[zfs-discuss] Help with setting up ZFS

2009-07-26 Thread Brian
Hello I recently purchased some hardware which I plan on turning into a data server. I purchased the following: 4 gigs of registered ECC ram 667 SuperMicro X7DCA motherboard (found it for really cheap and figured it couldn't be too bad)

Re: [zfs-discuss] Help with setting up ZFS

2009-07-26 Thread Erik Trimble
Brian wrote: Hello I recently purchased some hardware which I plan on turning into a data server. I purchased the following: 4 gigs of registered ECC ram 667 SuperMicro X7DCA motherboard (found it for really cheap and figured it couldn't be too bad)

Re: [zfs-discuss] The importance of ECC RAM for ZFS

2009-07-26 Thread Erik Trimble
dick hoogendijk wrote: On Sat, 25 Jul 2009 21:58:48 + (UTC) Marc Bevand m.bev...@gmail.com wrote: dick hoogendijk dick at nagual.nl writes: I live in Holland and it is not easy to find motherboards that (a) truly support ECC ram and (b) are (Open)Solaris compatible.

Re: [zfs-discuss] The importance of ECC RAM for ZFS

2009-07-26 Thread Erik Trimble
Erik Trimble wrote: I _believe_ all socket AM2, AM2+ and AM3 consumer chips (Phenom, Phenom II, Athlon X2, Athlon X3 and Athlon X4) also support unbuffered non-registered ECC. The AMD Specs page for the above processors indicates I'm right about those CPUs. Quick correction: the

Re: [zfs-discuss] Another user looses his pool (10TB) in this case and 40 days work

2009-07-26 Thread Frank Middleton
On 07/25/09 04:30 PM, Carson Gaspar wrote: No. You'll lose unwritten data, but won't corrupt the pool, because the on-disk state will be sane, as long as your iSCSI stack doesn't lie about data commits or ignore cache flush commands. Why is this so difficult for people to understand? Let me

Re: [zfs-discuss] ZFS Root Pool Recovery (from the FAQ)

2009-07-26 Thread Oscar del Rio
dick hoogendijk wrote: r...@westmark:/# share -...@store/snaps /store/snaps sec=sys,rw=arwen,root=arwen arwen# zfs send -Rv rp...@0906 /net/westmark/store/snaps/rpool.0906 zsh: permission denied: /net/westmark/store/snaps/rpool.0906 try sharing with the @ network syntax. See man

Re: [zfs-discuss] Another user looses his pool (10TB) in this case and 40 days work

2009-07-26 Thread Bob Friesenhahn
On Sun, 26 Jul 2009, David Magda wrote: That's the whole point of this thread: what should happen, or what should the file system do, when the drive (real or virtual) lies about the syncing? It's just as much a problem with any other POSIX file system (which have to deal with fsync(2))--ZFS

Re: [zfs-discuss] ZFS Root Pool Recovery (from the FAQ)

2009-07-26 Thread dick hoogendijk
On Sun, 26 Jul 2009 12:14:03 -0400 Oscar del Rio del...@mie.utoronto.ca wrote: dick hoogendijk wrote: r...@westmark:/# share -...@store/snaps /store/snaps sec=sys,rw=arwen,root=arwen arwen# zfs send -Rv rp...@0906 arwen# /net/westmark/store/snaps/rpool.0906 zsh:

Re: [zfs-discuss] When writing to SLOG at full speed all disk IO is blocked

2009-07-26 Thread Andre Lue
byleal, Can you share how to recreate or test this? -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Subscribing broken?

2009-07-26 Thread Tim Cook
What's the deal with the mailing list? I've unsubscribed an old email address, and attempted to sign up the new one 4 times now over the last month, and have yet to receive any updates/have it approved. Are the admins asleep at the helm for zfs-discuss or what? -- This message posted from

Re: [zfs-discuss] Help with setting up ZFS

2009-07-26 Thread Brian
Yea I have a cheap nvidia video card I found that should work with this. I found this MB at Fry's for under 100 dollars so I figured Id try it out. Its probably a discontinued line of server motherboards by SuperMicro so I figured it probably would be an OK board. 1.) Why would I put the

Re: [zfs-discuss] Help with setting up ZFS

2009-07-26 Thread Brian
Im sorry I forgot to ask again if its worth setting to the Time Limited Recovery to its Raid counterpart mode. The reason I ask is because all I can find to do this is a DOS file so Im not sure how I would go about doing it in OpenSolaris.

Re: [zfs-discuss] Help with setting up ZFS

2009-07-26 Thread Bob Friesenhahn
On Sun, 26 Jul 2009, Brian wrote: as its great for that but I decided to try out ZFS. Now I read that its advisable to scrub the system every week or month, is it possible just to make a script that will do this so I dont have to be there? Also I know ZFS can use blank hard drives that will

Re: [zfs-discuss] Another user looses his pool (10TB) in this case and 40 days work

2009-07-26 Thread Toby Thain
On 26-Jul-09, at 11:08 AM, Frank Middleton wrote: On 07/25/09 04:30 PM, Carson Gaspar wrote: No. You'll lose unwritten data, but won't corrupt the pool, because the on-disk state will be sane, as long as your iSCSI stack doesn't lie about data commits or ignore cache flush commands. Why is

Re: [zfs-discuss] Help with setting up ZFS

2009-07-26 Thread Erik Trimble
Brian wrote: Im sorry I forgot to ask again if its worth setting to the Time Limited Recovery to its Raid counterpart mode. The reason I ask is because all I can find to do this is a DOS file so Im not sure how I would go about doing it in OpenSolaris.