Generally, there should not be "corruption", only a roll-back to a previous
state. *HOWEVER*, its possible that an application which has state outside of
the filesystem (such as effects on network peers, or even state written to
*other* filesystems) will encounter a consistency problem as the a
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Bob Friesenhahn
>
> data formats like
> databases could become internally corrupted due to the data written in
> a zfs transaction group not being representative of a coherent
> database transa
On Thu, 10 Nov 2011, Tomas Forsman wrote:
Loss of data as seen by the client can definitely occur.
When a client writes something, and something else ends up on disk - I
call that corruption. Doesn't matter whose fault it is and technical
details, the wrong data was stored despite the client b
> disk. This behavior is what makes NFS over ZFS slow without a slog: NFS
does
> everything O_SYNC by default,
No, it doesn't. Howver VMWare by default issues all writes as SYNC.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Bob Friesenhahn
>
> The silent corruption (of zfs) does not occur due to simple reason
> that flushing all of the block writes are acknowledged by the disks
> and then a new transaction occurs
On 10 November, 2011 - Will Murnane sent me these 1,5K bytes:
> On Thu, Nov 10, 2011 at 14:12, Tomas Forsman wrote:
> > On 10 November, 2011 - Bob Friesenhahn sent me these 1,6K bytes:
> >> On Wed, 9 Nov 2011, Tomas Forsman wrote:
>
> At all times, if there's a server crash, ZFS will co
On Thu, Nov 10, 2011 at 14:12, Tomas Forsman wrote:
> On 10 November, 2011 - Bob Friesenhahn sent me these 1,6K bytes:
>> On Wed, 9 Nov 2011, Tomas Forsman wrote:
At all times, if there's a server crash, ZFS will come back along at next
boot or mount, and the filesystem will be in a
On 10 November, 2011 - Bob Friesenhahn sent me these 1,6K bytes:
> On Wed, 9 Nov 2011, Tomas Forsman wrote:
>>>
>>> At all times, if there's a server crash, ZFS will come back along at next
>>> boot or mount, and the filesystem will be in a consistent state, that was
>>> indeed a valid state which
On Wed, 9 Nov 2011, Tomas Forsman wrote:
At all times, if there's a server crash, ZFS will come back along at next
boot or mount, and the filesystem will be in a consistent state, that was
indeed a valid state which the filesystem actually passed through at some
moment in time. So as long as al
On Wed, November 9, 2011 10:35, Tomas Forsman wrote:
> Too bad NFS is resilient against servers coming and going..
NFSv4 is statefull, so server reboots are more noticeable. (This has
pluses and minuses.)
___
zfs-discuss mailing list
zfs-discuss@opens
On 08 November, 2011 - Edward Ned Harvey sent me these 2,9K bytes:
> > From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> > boun...@opensolaris.org] On Behalf Of Evaldas Auryla
> >
> > I'm trying to evaluate what are the risks of running NFS share of zfs
> > dataset with sync=disabl
On 11/ 9/11 03:11 PM, Edward Ned Harvey wrote:
From: Evaldas Auryla [mailto:evaldas.aur...@edqm.eu]
Sent: Wednesday, November 09, 2011 8:55 AM
I was thinking about STEC ZeusRAM, but unfortunately it's SAS only
device, and it won't make into X4540 (SATA ports only), so another
option could be ST
> From: Evaldas Auryla [mailto:evaldas.aur...@edqm.eu]
> Sent: Wednesday, November 09, 2011 8:55 AM
>
> I was thinking about STEC ZeusRAM, but unfortunately it's SAS only
> device, and it won't make into X4540 (SATA ports only), so another
> option could be STEC MACH16iops (50GB SLC SATA SSD).
Pe
On 11/ 9/11 01:42 AM, Edward Ned Harvey wrote:
I know a lot of people will say "don't do it," but that's only partial
truth. The real truth is:
At all times, if there's a server crash, ZFS will come back along at next
boot or mount, and the filesystem will be in a consistent state, that was
in
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Evaldas Auryla
>
> I'm trying to evaluate what are the risks of running NFS share of zfs
> dataset with sync=disabled property. The clients are vmware hosts in our
> environment and server is S
On Tue, November 8, 2011 09:38, Evaldas Auryla wrote:
> I'm trying to evaluate what are the risks of running NFS share of zfs
> dataset with sync=disabled property. The clients are vmware hosts in our
> environment and server is SunFire X4540 "Thor" system. Though general
> recommendation tells not
On Nov 8, 2011, at 6:38 AM, Evaldas Auryla wrote:
> Hi all,
>
> I'm trying to evaluate what are the risks of running NFS share of zfs dataset
> with sync=disabled property. The clients are vmware hosts in our environment
> and server is SunFire X4540 "Thor" system. Though general recommendatio
Hi all,
I'm trying to evaluate what are the risks of running NFS share of zfs
dataset with sync=disabled property. The clients are vmware hosts in our
environment and server is SunFire X4540 "Thor" system. Though general
recommendation tells not to do this, but after testing performance with
18 matches
Mail list logo
