2010-06-09 15:45:30

by Theodore Ts'o

[permalink] [raw]
Subject: Re: [PATCHv4 01/17] VFS: introduce helpers for the s_dirty flag

On Fri, May 28, 2010 at 02:17:55PM -0700, Andrew Morton wrote:
> >
> > The real issue is that it's almost certainly an overdesign. Let's
> > get rid of the bogus uses first and figure out what's happening in
> > what remains, OK?
>
> That would be good.

Can we figure out what the new names will be for these accessor
functions, and then pursuade Linus to be willing to add patch #1 in
this series to add these accessor functions (without any users for
these functions, that would wait until the next merge window) to
2.6.35-rc3 or -rc4, please?

It will make life much easier for fs maintainers to merge the patches,
especially if they've done some cleanup to reduce the bogus places
where s_dirt was getting set in the first place. That way I can apply
my patch to reduce the use of s_dirt[1], then apply a patch I carry in
my own tree to convert to the new accessor functions without worrying
about patch conflicts.

[1] http://article.gmane.org/gmane.comp.file-systems.ext4/19499

Thanks,

- Ted


2010-06-09 15:52:58

by Artem Bityutskiy

[permalink] [raw]
Subject: Re: [PATCHv4 01/17] VFS: introduce helpers for the s_dirty flag

On Wed, 2010-06-09 at 11:44 -0400, [email protected] wrote:
> On Fri, May 28, 2010 at 02:17:55PM -0700, Andrew Morton wrote:
> > >
> > > The real issue is that it's almost certainly an overdesign. Let's
> > > get rid of the bogus uses first and figure out what's happening in
> > > what remains, OK?
> >
> > That would be good.
>
> Can we figure out what the new names will be for these accessor
> functions, and then pursuade Linus to be willing to add patch #1 in
> this series to add these accessor functions (without any users for
> these functions, that would wait until the next merge window) to
> 2.6.35-rc3 or -rc4, please?
>
> It will make life much easier for fs maintainers to merge the patches,
> especially if they've done some cleanup to reduce the bogus places
> where s_dirt was getting set in the first place. That way I can apply
> my patch to reduce the use of s_dirt[1], then apply a patch I carry in
> my own tree to convert to the new accessor functions without worrying
> about patch conflicts.

Yes, that would be nice, Al?

--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

2010-06-09 16:32:48

by Andrew Morton

[permalink] [raw]
Subject: Re: [PATCHv4 01/17] VFS: introduce helpers for the s_dirty flag

On Wed, 9 Jun 2010 11:44:49 -0400 [email protected] wrote:

> On Fri, May 28, 2010 at 02:17:55PM -0700, Andrew Morton wrote:
> > >
> > > The real issue is that it's almost certainly an overdesign. Let's
> > > get rid of the bogus uses first and figure out what's happening in
> > > what remains, OK?
> >
> > That would be good.
>
> Can we figure out what the new names will be for these accessor
> functions,

sb_mark_dirty(), sb_mark_clean(), sb_is_dirty().

> and then pursuade Linus to be willing to add patch #1 in
> this series to add these accessor functions (without any users for
> these functions, that would wait until the next merge window) to
> 2.6.35-rc3 or -rc4, please?

I expect he'd be OK with that.

> It will make life much easier for fs maintainers to merge the patches,
> especially if they've done some cleanup to reduce the bogus places
> where s_dirt was getting set in the first place.

For that reason.

2010-06-09 22:33:36

by Al Viro

[permalink] [raw]
Subject: Re: [PATCHv4 01/17] VFS: introduce helpers for the s_dirty flag

On Wed, Jun 09, 2010 at 09:31:57AM -0700, Andrew Morton wrote:
> > Can we figure out what the new names will be for these accessor
> > functions,
>
> sb_mark_dirty(), sb_mark_clean(), sb_is_dirty().

Fine by me. If Linus doesn't take such a patch, I certainly will and put
it into for-next ASAP.