Re: [zfs-discuss] FS Reliability WAS: about btrfs and zfs

2011-10-25 Thread Fred Liu
Paul, Thanks. I understand now. Fred -Original Message- From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Paul Kraus Sent: 星期一, 十月 24, 2011 22:38 To: ZFS Discussions Subject: Re: [zfs-discuss] FS Reliability WAS: about btrfs

Re: [zfs-discuss] FS Reliability WAS: about btrfs and zfs

2011-10-25 Thread Fred Liu
Some people have trained their fingers to use the -f option on every command that supports it to force the operation. For instance, how often do you do rm -rf vs. rm -r and answer questions about every file? If various zpool commands (import, create, replace, etc.) are used against the

Re: [zfs-discuss] FS Reliability WAS: about btrfs and zfs

2011-10-25 Thread Paul Kraus
On Fri, Oct 21, 2011 at 9:33 PM, Mike Gerdts mger...@gmail.com wrote: Some people have trained their fingers to use the -f option on every command that supports it to force the operation.  For instance, how often do you do rm -rf vs. rm -r and answer questions about every file? The last

Re: [zfs-discuss] FS Reliability WAS: about btrfs and zfs

2011-10-24 Thread Paul Kraus
On Sat, Oct 22, 2011 at 12:36 AM, Paul Kraus p...@kraus-haus.org wrote: Recently someone posted to this list of that _exact_ situation, they loaded an OS to a pair of drives while a pair of different drives containing an OS were still attached. The zpool on the first pair ended up not being

Re: [zfs-discuss] FS Reliability WAS: about btrfs and zfs

2011-10-22 Thread Fajar A. Nugraha
On Sat, Oct 22, 2011 at 11:36 AM, Paul Kraus p...@kraus-haus.org wrote: Recently someone posted to this list of that _exact_ situation, they loaded an OS to a pair of drives while a pair of different drives containing an OS were still attached. The zpool on the first pair ended up not being

Re: [zfs-discuss] FS Reliability WAS: about btrfs and zfs

2011-10-21 Thread Fred Liu
3. Do NOT let a system see drives with more than one OS zpool at the same time (I know you _can_ do this safely, but I have seen too many horror stories on this list that I just avoid it). Can you elaborate #3? In what situation will it happen? Thanks. Fred

Re: [zfs-discuss] FS Reliability WAS: about btrfs and zfs

2011-10-21 Thread Mike Gerdts
On Fri, Oct 21, 2011 at 8:02 PM, Fred Liu fred_...@issi.com wrote: 3. Do NOT let a system see drives with more than one OS zpool at the same time (I know you _can_ do this safely, but I have seen too many horror stories on this list that I just avoid it). Can you elaborate #3? In what

Re: [zfs-discuss] FS Reliability WAS: about btrfs and zfs

2011-10-21 Thread Paul Kraus
Recently someone posted to this list of that _exact_ situation, they loaded an OS to a pair of drives while a pair of different drives containing an OS were still attached. The zpool on the first pair ended up not being able to be imported, and were corrupted. I can post more info when I am back

[zfs-discuss] FS Reliability WAS: about btrfs and zfs

2011-10-18 Thread Paul Kraus
On Tue, Oct 18, 2011 at 9:38 AM, Gregory Shaw greg.s...@oracle.com wrote: Another item that made me nervous was my experience with ZFS.  Even when called 'ready for production', a number of bugs were found that were pretty nasty. They've since been fixed (years ago), but there were some

Re: [zfs-discuss] FS Reliability WAS: about btrfs and zfs

2011-10-18 Thread Cindy Swearingen
Hi Paul, Your 1-3 is very sensible advice and I must ask about this statement: I have yet to have any data loss with ZFS. Maybe this goes without saying, but I think you are using ZFS redundancy. Thanks, Cindy On 10/18/11 08:52, Paul Kraus wrote: On Tue, Oct 18, 2011 at 9:38 AM, Gregory

Re: [zfs-discuss] FS Reliability WAS: about btrfs and zfs

2011-10-18 Thread Paul Kraus
On Tue, Oct 18, 2011 at 12:53 PM, Cindy Swearingen cindy.swearin...@oracle.com wrote: Your 1-3 is very sensible advice Unfortunately, I don't think I have ever seen the recommendations I made stated quite so plainly. and I must ask about this statement: I have yet to have any data loss