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 > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 03-25-2009, 02:27 PM
Jens Axboe
 
Default Barriers still not passing on simple dm devices...

On Wed, Mar 25 2009, Mikulas Patocka wrote:
> > > > Over time we should have support everywhere, but it needs to be checked,
> > > > audited, and trusted.
> > >
> > > BTW. What is the rule for barriers if the device can't prevent the
> > > requests from being delayed or reordered? (for example ATA<=3 disks with
> > > cache that lack cache-flush command ... or flash cards that do
> > > write-caching anyway and it can't be turned off). Should they support
> > > barriers and try to make best effort? Or should they reject barriers to
> > > inform the caller code that they have no data consistency?
> >
> > If they can't flush cache, then they must reject barriers unless they
> > have write through caching.
>
> ... and you suppose that journaled filesystems will use this error and
> mark filesystem for fsck if they are running over a device that doesn't
> support consistency?

No, but they can warn that data consistency isn't guarenteed. And they
all do, if you mount with barriers enabled and the barrier write fails.
If barriers aren't support, the first one will fail. So either they do
lazy detect, or they do a trial barrier write at mount time.

So yes, I suppose that file systems will use this error. Because that is
what they do.

> In theory it would be nice, in practice it doesn't work this way because
> many devices *DO* support data consistency don't support barriers (the
> most common are DM and MD when run over disk without write cache).

Your theory is nice, but most dm systems use write back caching. Any
desktop uses write back caching. Only higher end disks default to
write-through caching.

> So I think there should be flag (this device does/doesn't support data
> consistency) that the journaled filesystems can use to mark the disk dirty
> for fsck. And if you implement this flag, you can accept barriers always
> to all kind of devices regardless of whether they support consistency. You
> can then get rid of that -EOPNOTSUPP and simplify filesystem code because
> they'd no longer need two commit paths and a clumsy way to restart
> -EOPNOTSUPPed requests.

And my point is that this case isn't interesting, because most setups
don't guarantee proper ordering. The error handling is complex, no doubt
about that. But the trial barrier test is pretty trivial and even could
be easily abstracted out. If a later barrier write fails, then that's
really no different than if a normal write fails. Error handling is not
easy in that case.

--
Jens Axboe

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-25-2009, 09:39 PM
Mikulas Patocka
 
Default Barriers still not passing on simple dm devices...

> > > If they can't flush cache, then they must reject barriers unless they
> > > have write through caching.
> >
> > ... and you suppose that journaled filesystems will use this error and
> > mark filesystem for fsck if they are running over a device that doesn't
> > support consistency?
>
> No, but they can warn that data consistency isn't guarenteed. And they
> all do, if you mount with barriers enabled and the barrier write fails.
> If barriers aren't support, the first one will fail. So either they do
> lazy detect, or they do a trial barrier write at mount time.

The user shouldn't really be required to know what are barriers, which
drivers support them and which don't, and which drivers maintain
consistency without barriers and which not.

The user only needs to know if he must run fsck in the case of power
failure or not. --- and that -EOPNOTSUPP error and warnings about failed
barriers give him no information about that.

> So yes, I suppose that file systems will use this error. Because that is
> what they do.
>
> > In theory it would be nice, in practice it doesn't work this way because
> > many devices *DO* support data consistency don't support barriers (the
> > most common are DM and MD when run over disk without write cache).
>
> Your theory is nice, but most dm systems use write back caching. Any

If they do, the filesystem should know about it and fsck the partition in
the case of crash.

> desktop uses write back caching. Only higher end disks default to
> write-through caching.
>
> > So I think there should be flag (this device does/doesn't support data
> > consistency) that the journaled filesystems can use to mark the disk dirty
> > for fsck. And if you implement this flag, you can accept barriers always
> > to all kind of devices regardless of whether they support consistency. You
> > can then get rid of that -EOPNOTSUPP and simplify filesystem code because
> > they'd no longer need two commit paths and a clumsy way to restart
> > -EOPNOTSUPPed requests.
>
> And my point is that this case isn't interesting, because most setups
> don't guarantee proper ordering.

If the ordering isn't guaranteed, the filesystem should know about it, and
mark the partition for fsck. That's why I'm suggesting to use a flag for
that. That flag could be also propagated up through md and dm.

The reasoning: "write barriers aren't supported => the device doesn't
guarantee consistency" isn't valid.

> The error handling is complex, no doubt
> about that. But the trial barrier test is pretty trivial and even could
> be easily abstracted out. If a later barrier write fails, then that's
> really no different than if a normal write fails. Error handling is not
> easy in that case.

I had a discussion with Andi about it some times ago. The conclusion was
that all the current filesystems handle barriers failing in the middle of
the operation without functionality loss, but it makes barriers useless
for any performance-sensitive tasks (commits that wouldn't block
concurrent activity). Non-blocking commits could only be implemented if
barriers don't fail.

Mikulas

> -- Jens Axboe
>

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-25-2009, 09:39 PM
Mikulas Patocka
 
Default Barriers still not passing on simple dm devices...

> > > If they can't flush cache, then they must reject barriers unless they
> > > have write through caching.
> >
> > ... and you suppose that journaled filesystems will use this error and
> > mark filesystem for fsck if they are running over a device that doesn't
> > support consistency?
>
> No, but they can warn that data consistency isn't guarenteed. And they
> all do, if you mount with barriers enabled and the barrier write fails.
> If barriers aren't support, the first one will fail. So either they do
> lazy detect, or they do a trial barrier write at mount time.

The user shouldn't really be required to know what are barriers, which
drivers support them and which don't, and which drivers maintain
consistency without barriers and which not.

The user only needs to know if he must run fsck in the case of power
failure or not. --- and that -EOPNOTSUPP error and warnings about failed
barriers give him no information about that.

> So yes, I suppose that file systems will use this error. Because that is
> what they do.
>
> > In theory it would be nice, in practice it doesn't work this way because
> > many devices *DO* support data consistency don't support barriers (the
> > most common are DM and MD when run over disk without write cache).
>
> Your theory is nice, but most dm systems use write back caching. Any

If they do, the filesystem should know about it and fsck the partition in
the case of crash.

> desktop uses write back caching. Only higher end disks default to
> write-through caching.
>
> > So I think there should be flag (this device does/doesn't support data
> > consistency) that the journaled filesystems can use to mark the disk dirty
> > for fsck. And if you implement this flag, you can accept barriers always
> > to all kind of devices regardless of whether they support consistency. You
> > can then get rid of that -EOPNOTSUPP and simplify filesystem code because
> > they'd no longer need two commit paths and a clumsy way to restart
> > -EOPNOTSUPPed requests.
>
> And my point is that this case isn't interesting, because most setups
> don't guarantee proper ordering.

If the ordering isn't guaranteed, the filesystem should know about it, and
mark the partition for fsck. That's why I'm suggesting to use a flag for
that. That flag could be also propagated up through md and dm.

The reasoning: "write barriers aren't supported => the device doesn't
guarantee consistency" isn't valid.

> The error handling is complex, no doubt
> about that. But the trial barrier test is pretty trivial and even could
> be easily abstracted out. If a later barrier write fails, then that's
> really no different than if a normal write fails. Error handling is not
> easy in that case.

I had a discussion with Andi about it some times ago. The conclusion was
that all the current filesystems handle barriers failing in the middle of
the operation without functionality loss, but it makes barriers useless
for any performance-sensitive tasks (commits that wouldn't block
concurrent activity). Non-blocking commits could only be implemented if
barriers don't fail.

Mikulas

> -- Jens Axboe
>

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 10:38 PM.

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