FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EXT3 Users

 
 
LinkBack Thread Tools
 
Old 01-30-2009, 12:53 PM
Nicolas KOWALSKI
 
Default barrier and commit options?

Hello,

On my home server (Debian etch, custom 2.6.28.2 kernel), I am using ext3
for both root and /home filesystems, with barriers enabled to prevent
corruption caused by my PATA disk write cache.

Looking for a better performance, I have also set the commit=nr option
as described in linux-2.6.28.2/Documentation/filesystems/ext3.txt, so
that I now have:

niko@petole:~$ mount -t ext3
/dev/sda1 on / type ext3 (rw,noatime,commit=30,barrier=1)
/dev/sda3 on /home type ext3 (rw,noatime,commit=30,barrier=1)


I know I may loose the last 30 seconds of "work" (it's just a home
server), but is the filesystem at risk (corruption, whatever, ...) with
these mount options ?

Thanks,
--
Nicolas

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 01-30-2009, 02:17 PM
Christian Kujau
 
Default barrier and commit options?

On Fri, 30 Jan 2009, Nicolas KOWALSKI wrote:

I know I may loose the last 30 seconds of "work" (it's just a home
server), but is the filesystem at risk (corruption, whatever, ...) with
these mount options ?


No, why would it? If certain mount options would make a filesystem prone
to corruption I'd consider this a bug. So apart from losing a few more
seconds of work in case of an error, the fs should be fine.


C.
--
BOFH excuse #199:

the curls in your keyboard cord are losing electricity.

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 01-30-2009, 02:22 PM
Eric Sandeen
 
Default barrier and commit options?

Christian Kujau wrote:
> On Fri, 30 Jan 2009, Nicolas KOWALSKI wrote:
>> I know I may loose the last 30 seconds of "work" (it's just a home
>> server), but is the filesystem at risk (corruption, whatever, ...) with
>> these mount options ?
>
> No, why would it? If certain mount options would make a filesystem prone
> to corruption I'd consider this a bug.

Well, that's not exactly true. Turning off barriers, depending on your
storage, could lead to corruption in some cases. Mounting with
data=writeback can expose stale data, which could even be a security issue.

But as long as you make these decisions consciously, they may fit your
needs.

> So apart from losing a few more
> seconds of work in case of an error, the fs should be fine.

This part is correct, barriers on and longer commit time should not
affect filesystem consistency / integrity.

-Eric

> C.

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 01-30-2009, 02:25 PM
Nicolas KOWALSKI
 
Default barrier and commit options?

On Fri, Jan 30, 2009 at 04:17:54PM +0100, Christian Kujau wrote:
> On Fri, 30 Jan 2009, Nicolas KOWALSKI wrote:
>> I know I may loose the last 30 seconds of "work" (it's just a home
>> server), but is the filesystem at risk (corruption, whatever, ...) with
>> these mount options ?
>
> No, why would it? If certain mount options would make a filesystem prone
> to corruption I'd consider this a bug.

Well, not using barrier=1 with disk write cache enabled may cause
corruption apparently...

> So apart from losing a few more seconds of work in case of an error,
> the fs should be fine.

Fine.


Thanks for your reply,
--
Nicolas

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 01-30-2009, 02:30 PM
Nicolas KOWALSKI
 
Default barrier and commit options?

On Fri, Jan 30, 2009 at 10:22:46AM -0500, Eric Sandeen wrote:
> Christian Kujau wrote:
> > On Fri, 30 Jan 2009, Nicolas KOWALSKI wrote:
> >> I know I may loose the last 30 seconds of "work" (it's just a home
> >> server), but is the filesystem at risk (corruption, whatever, ...) with
> >> these mount options ?
> >
> > No, why would it? If certain mount options would make a filesystem prone
> > to corruption I'd consider this a bug.
>
> Well, that's not exactly true. Turning off barriers, depending on your
> storage, could lead to corruption in some cases. Mounting with
> data=writeback can expose stale data, which could even be a security issue.
>
> But as long as you make these decisions consciously, they may fit your
> needs.
>
> > So apart from losing a few more
> > seconds of work in case of an error, the fs should be fine.
>
> This part is correct, barriers on and longer commit time should not
> affect filesystem consistency / integrity.

Ok, I'm more relaxed about my data then.

Thanks for your reply,
--
Nicolas

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 01-30-2009, 02:34 PM
"Miller, Mike (OS Dev)"
 
Default barrier and commit options?

Eric wrote:
>
> Christian Kujau wrote:
> > On Fri, 30 Jan 2009, Nicolas KOWALSKI wrote:
> >> I know I may loose the last 30 seconds of "work" (it's just a home
> >> server), but is the filesystem at risk (corruption, whatever, ...)
> >> with these mount options ?
> >
> > No, why would it? If certain mount options would make a filesystem
> > prone to corruption I'd consider this a bug.
>
> Well, that's not exactly true. Turning off barriers,
> depending on your storage, could lead to corruption in some

I hope this a proper forum for this inquiry. I'm the maintainer of the HP Smart Array driver, cciss. We've had requests and now a bug report to support write barriers.
It seems that write barriers are primarily intended to ensure the proper ordering of data from the disks write cache to the medium. Is this accurate?

Thanks,
-- mikem

> cases. Mounting with data=writeback can expose stale data,
> which could even be a security issue.
>
> But as long as you make these decisions consciously, they may
> fit your needs.
>
> > So apart from losing a few more
> > seconds of work in case of an error, the fs should be fine.
>
> This part is correct, barriers on and longer commit time
> should not affect filesystem consistency / integrity.
>
> -Eric
>
> > C.
>
> _______________________________________________
> Ext3-users mailing list
> Ext3-users@redhat.com
> https://www.redhat.com/mailman/listinfo/ext3-users
>

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 01-30-2009, 02:40 PM
Ric Wheeler
 
Default barrier and commit options?

Miller, Mike (OS Dev) wrote:

Eric wrote:


Christian Kujau wrote:


On Fri, 30 Jan 2009, Nicolas KOWALSKI wrote:

I know I may loose the last 30 seconds of "work" (it's just a home
server), but is the filesystem at risk (corruption, whatever, ...)
with these mount options ?

No, why would it? If certain mount options would make a filesystem
prone to corruption I'd consider this a bug.

Well, that's not exactly true. Turning off barriers,
depending on your storage, could lead to corruption in some



I hope this a proper forum for this inquiry. I'm the maintainer of the HP Smart Array driver, cciss. We've had requests and now a bug report to support write barriers.
It seems that write barriers are primarily intended to ensure the proper ordering of data from the disks write cache to the medium. Is this accurate?


Thanks,
-- mikem



Hi Mike,

Without working barriers, you are especially open to metadata corruption
- If I remember the details correctly, Chris Mason has demonstrated a
50% chance of corruption directory entries in ext3 for example.


In addition, barriers allows fsync to have real meaning since the target
storage will flush its write cache & the user will have that fsync()
data after a power outage.


If you have a battery backed write cache (say, in a high end array)
barriers can be ignored since the storage can effectively make that
write cache non-volatile, but otherwise, this is pretty key for anyone
wanting to maintain data integrity,


Regards,

Ric

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 01-30-2009, 02:56 PM
"Miller, Mike (OS Dev)"
 
Default barrier and commit options?

Ric Wheeler wrote:

> > I hope this a proper forum for this inquiry. I'm the
> maintainer of the HP Smart Array driver, cciss. We've had
> requests and now a bug report to support write barriers.
> > It seems that write barriers are primarily intended to
> ensure the proper ordering of data from the disks write cache
> to the medium. Is this accurate?
> >
> > Thanks,
> > -- mikem
> >
> >
> Hi Mike,
>
> Without working barriers, you are especially open to metadata
> corruption
> - If I remember the details correctly, Chris Mason has
> demonstrated a 50% chance of corruption directory entries in
> ext3 for example.
>
> In addition, barriers allows fsync to have real meaning since
> the target storage will flush its write cache & the user will
> have that fsync() data after a power outage.
>
> If you have a battery backed write cache (say, in a high end
> array) barriers can be ignored since the storage can
> effectively make that write cache non-volatile, but
> otherwise, this is pretty key for anyone wanting to maintain
> data integrity,
>
Hi Ric,
That's what I getting at, array controllers with a battery backed write cache (BBWC). We disable the write cache on the physical disks and provide no mechanism to re-enable the cache except in some SATA configurations.

So my real question is this: Given the fact that many Smart Array controllers ship with a BBWC, will write barriers offer any benefit? I think fsync does nothing on SA since it doesn't know how to flush the controller cache.

If a user has no BBWC then all writes are completed all the way down to the disk medium before the command is completed back up to the driver.

Thanks,
-- mikem

>
> _______________________________________________
> Ext3-users mailing list
> Ext3-users@redhat.com
> https://www.redhat.com/mailman/listinfo/ext3-users
>

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 01-30-2009, 03:03 PM
Ric Wheeler
 
Default barrier and commit options?

Miller, Mike (OS Dev) wrote:
Ric Wheeler wrote:


I hope this a proper forum for this inquiry. I'm the

maintainer of the HP Smart Array driver, cciss. We've had
requests and now a bug report to support write barriers.

It seems that write barriers are primarily intended to

ensure the proper ordering of data from the disks write cache
to the medium. Is this accurate?


Thanks,
-- mikem




Hi Mike,

Without working barriers, you are especially open to metadata
corruption
- If I remember the details correctly, Chris Mason has
demonstrated a 50% chance of corruption directory entries in
ext3 for example.


In addition, barriers allows fsync to have real meaning since
the target storage will flush its write cache & the user will
have that fsync() data after a power outage.


If you have a battery backed write cache (say, in a high end
array) barriers can be ignored since the storage can
effectively make that write cache non-volatile, but
otherwise, this is pretty key for anyone wanting to maintain
data integrity,




Hi Ric,
That's what I getting at, array controllers with a battery backed write cache (BBWC). We disable the write cache on the physical disks and provide no mechanism to re-enable the cache except in some SATA configurations.

So my real question is this: Given the fact that many Smart Array controllers ship with a BBWC, will write barriers offer any benefit? I think fsync does nothing on SA since it doesn't know how to flush the controller cache.

If a user has no BBWC then all writes are completed all the way down to the disk medium before the command is completed back up to the driver.

Thanks,
-- mikem



In this case (or whenever the write cache is disabled on the disk) the
barrier ops don't do anything for us... Some devices simply ignore the
flush commands (imagine flushing the gigabytes in an enterprise array on
each transaction commit), others might return an error on the flush
command itself (which should be handled correctly).


I don't think that you need to add support if the HBA has a battery
backed cache and the target drives have disabled write caches...


Ric



_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users



_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 01-30-2009, 09:02 PM
Theodore Tso
 
Default barrier and commit options?

>>> - If I remember the details correctly, Chris Mason has demonstrated a
>>> 50% chance of corruption directory entries in ext3 for example.

Chris Mason has a script which forces the system to be under a lot of
memory pressure, and in that scenario, it is highly likely that
without barriers, there will be filesystem corruptions if the system
is abruptly turned off while his script is running.

Andrew Monrton has been resistant in making barriers=1 be the default
for ext3 because (as I understand it) he disbelieves that this is an
adequate real-world example, and there is a real performance hit to
running without barriers.

>>> If you have a battery backed write cache (say, in a high end array)
>>> barriers can be ignored since the storage can effectively make that
>>> write cache non-volatile, but otherwise, this is pretty key for
>>> anyone wanting to maintain data integrity,
>>>
>> That's what I getting at, array controllers with a battery backed
>> write cache (BBWC). We disable the write cache on the physical
>> disks and provide no mechanism to re-enable the cache except in
>> some SATA configurations.

Well, we still need the barrier on the block I/O elevantor side to
make sure that requests don't get reordered in the block layer. But
what you're saying is that once the write is posted to the array, it
is guaranteed that it is on "stable storage" (even if it is BBWC) such
that if someone hits the Big Red Switch at the exit to the data
center, and power is forcibly cut from the entire data center in case
of a fire, the battery will still keep the cache alive, at least until
the sprinklers go off, anyway, right? :-)

In that case, I suspect the right thing for the cciss array to do is
to ignore the barrier, but not to return an error. If you return an
error, and refuse the write with barrier operation (which is what the
cciss driver seems to be doing starting in 2.6.29-rcX), ext4 will
retry the write without the barrier, at which point we are vulnerable
to the block layer reordering things at the I/O scheduler layer. In
effect, you're claiming that every single write to cciss is implicitly
a "barrier write" in that once it is received by the device, it is
guaranteed not to be lost even if the power to the entire system is
forcibly removed.

- Ted


_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 

Thread Tools




All times are GMT. The time now is 01:30 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org