Jens Axboe wrote:
On Thu, May 31 2007, Phillip Susi wrote:
Jens Axboe wrote:
No Stephan is right, the barrier is both an ordering and integrity
constraint. If a driver completes a barrier request before that request
and previously submitted requests are on STABLE storage, then it
violat
Neil Brown wrote:
On Friday June 1, [EMAIL PROTECTED] wrote:
On Thu, May 31, 2007 at 02:31:21PM -0400, Phillip Susi wrote:
David Chinner wrote:
That sounds like a good idea - we can leave the existing
WRITE_BARRIER behaviour unchanged and introduce a new WRITE_ORDERED
behaviour
On Fri, 2007-06-01 at 14:21 +0200, Michal Piotrowski wrote:
> File systems
>
> Subject: JFFS2 issues
> References :
> http://lists.infradead.org/pipermail/linux-mtd/2007-May/018426.html
> Submitter : Haavard Skinnemoen <[EMAIL PROTECTED]>
> Caused-By : commit 10731f83009e2556f98ffa5c7c2cbffe
[EMAIL PROTECTED] wrote:
> On Fri, 01 Jun 2007 16:16:01 +0900, Tejun Heo said:
>> Don't those thingies usually have NV cache or backed by battery such
>> that ORDERED_DRAIN is enough?
>
> Probably *most* do, but do you really want to bet the user's data on it?
Thought we were talking about high-e
On Fri, Jun 01, 2007 at 11:41:23AM -0600, Matthew Wilcox wrote:
> Samba internally prohibits renaming or deleting an open file, to match
> Windows semantics. So it won't notice the difference. At least, that's
> what I remember from a discussion with Tridge when we were implementing
> leases back
On Fri, Jun 01, 2007 at 12:44:16PM -0400, J. Bruce Fields wrote:
> The only problem I'm aware of is that leases aren't broken on rename,
> link, and unlink. This is kind of tricky to fix. David Richter (cc'd)
> and I sketched out a few different approaches, and I think he has some
> patches imple
On Fri, 01 Jun 2007 16:16:01 +0900, Tejun Heo said:
> Don't those thingies usually have NV cache or backed by battery such
> that ORDERED_DRAIN is enough?
Probably *most* do, but do you really want to bet the user's data on it?
> The problem is that the interface between the host and a storage de
On Thu, May 31, 2007 at 06:34:09PM -0400, Trond Myklebust wrote:
> On Thu, 2007-05-31 at 17:40 -0400, J. Bruce Fields wrote:
> > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > index 7cf0c54..09aefb4 100644
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -1112,6 +1112,7 @@
On Fri, Jun 01, 2007 at 09:14:53AM -0400, Peter Staubach wrote:
> J. Bruce Fields wrote:
> >From: J. Bruce Fields <[EMAIL PROTECTED]>
> >
> >Currently leases are only kept locally, so there's no way for a distributed
> >filesystem to enforce them against multiple clients. We're particularly
> >int
On Fri, 2007-06-01 at 12:30 -0400, J. Bruce Fields wrote:
> On Thu, May 31, 2007 at 05:51:37PM -0400, Trond Myklebust wrote:
> > Why not move the security checks from setlease() into __setlease()? That
> > way you can continue to avoid the calls to (re)take the BKL, which are
> > redundant as far a
On Thu, May 31, 2007 at 05:51:37PM -0400, Trond Myklebust wrote:
> Why not move the security checks from setlease() into __setlease()? That
> way you can continue to avoid the calls to (re)take the BKL, which are
> redundant as far as fcntl_setlease() is concerned.
Sure. Then setlease() just beco
Jens Axboe wrote:
On Thu, May 31 2007, Bill Davidsen wrote:
Jens Axboe wrote:
On Thu, May 31 2007, David Chinner wrote:
On Thu, May 31, 2007 at 08:26:45AM +0200, Jens Axboe wrote:
On Thu, May 31 2007, David Chinner wrote:
IOWs, there are two par
Hi!
> >> Average users are not supposed to be writing security policy. To be
> >> honest, even average-level system administrators should not be
> >> writing security policy.
> That explains so much! "SELinux: you're too dumb to use it, so just keep
> your hands in your pockets." :-)
>
> App
J. Bruce Fields wrote:
From: J. Bruce Fields <[EMAIL PROTECTED]>
Currently leases are only kept locally, so there's no way for a distributed
filesystem to enforce them against multiple clients. We're particularly
interested in the case of nfsd exporting a cluster filesystem, in which
case nfsd
Hi all,
Here is a list of some known regressions in 2.6.22-rc3
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
ARM
Subject: arch/arm/plat-s3c24xx/devs.c build errors
References : http://lkml.org/lkml/2007/5/28/18
Submit
On Thu, 31 May 2007 15:46:48 -0700, Andrew Morton wrote:
> >
> > I_LOCK was used for several unrelated purposes, which caused deadlock
> > situations in certain filesystems as a side effect. One of the purposes
> > now uses the new I_SYNC bit.
>
> Do we know what those deadlocks were? It's a bi
On Fri, 1 June 2007 09:59:17 +0100, Anton Altaparmakov wrote:
>
> I agree that your patch is a good idea. I reviewed the latest
> incarnation and it makes sense to me. And your comment concerning
Thanks.
> the flags is a very welcome addition. Probably ought to find its way
> into Docum
On Fri, Jun 01, 2007 at 11:53:13AM +0200, Miklos Szeredi wrote:
> > On Fri, Jun 01, 2007 at 09:49:05AM +0100, Christoph Hellwig wrote:
> > > On Fri, Jun 01, 2007 at 10:33:09AM +0200, Karel Zak wrote:
> > > > The core of the problem is that HAL doesn't have entries in
> > > > /etc/fstab, so you ca
> On Fri, Jun 01, 2007 at 09:49:05AM +0100, Christoph Hellwig wrote:
> > On Fri, Jun 01, 2007 at 10:33:09AM +0200, Karel Zak wrote:
> > > The core of the problem is that HAL doesn't have entries in
> > > /etc/fstab, so you cannot check for "user=" and "users=" by
> > > umount(8). The HAL have en
On Fri, Jun 01, 2007 at 09:49:05AM +0100, Christoph Hellwig wrote:
> On Fri, Jun 01, 2007 at 10:33:09AM +0200, Karel Zak wrote:
> > The core of the problem is that HAL doesn't have entries in
> > /etc/fstab, so you cannot check for "user=" and "users=" by
> > umount(8). The HAL have enough infor
Hi,
On 16 May 2007, at 18:01, Jörn Engel wrote:
Patches fixes a deadlock problem well enough for LogFS to survive.
The
problem itself is generic and seems to be ancient. Shaggy has code in
JFS from about 2.4.20 that seems to work around the deadlock. Dave
Chinner indicated that this could c
On Fri, Jun 01, 2007 at 10:33:09AM +0200, Karel Zak wrote:
> The core of the problem is that HAL doesn't have entries in
> /etc/fstab, so you cannot check for "user=" and "users=" by
> umount(8). The HAL have enough information about user's privileges,
> but the umount(8) knows nothing.
Please
Karel Zak <[EMAIL PROTECTED]> writes:
> There is more things:
>
> uhelper=
>
>... this one is my baby :-(
>
>(Not released by upstream yet. ...according to Google this
>Fedora patch is already in Mandrake, PCLinuxOS, Pardus, and
>??? )
and openSuse Factory...
On Fri, Jun 01, 2007 at 09:03:42AM +0200, Miklos Szeredi wrote:
> > uhelper=
> >
> >... this one is my baby :-(
> >
> >(Not released by upstream yet. ...according to Google this
> >Fedora patch is already in Mandrake, PCLinuxOS, Pardus, and
> >??? )
> >
> >
On Fri, Jun 01 2007, Tejun Heo wrote:
> Jens Axboe wrote:
> > On Thu, May 31 2007, David Chinner wrote:
> >> On Thu, May 31, 2007 at 08:26:45AM +0200, Jens Axboe wrote:
> >>> On Thu, May 31 2007, David Chinner wrote:
> IOWs, there are two parts to the problem:
>
> 1 - guaranteeing I
On Fri, Jun 01, 2007 at 03:59:51PM +1000, Neil Brown wrote:
> On Friday June 1, [EMAIL PROTECTED] wrote:
> > On Thu, May 31, 2007 at 02:31:21PM -0400, Phillip Susi wrote:
> > > David Chinner wrote:
> > > >That sounds like a good idea - we can leave the existing
> > > >WRITE_BARRIER behaviour unchan
On Thu, May 31, 2007 at 05:11:40PM -0700, H. Peter Anvin wrote:
> Trond Myklebust wrote:
>
> >>> A lot of these could be fixed all at once by letting the filesystem tell
> >>> the VFS to retain the string passed to the original mount. That will
> >> Unfortunately, the original option string
[ cc'ing Ric Wheeler for storage array thingie. Hi, whole thread is at
http://thread.gmane.org/gmane.linux.kernel.device-mapper.devel/3344 ]
Hello,
[EMAIL PROTECTED] wrote:
> but when you consider the self-contained disk arrays it's an entirely
> different story. you can easily have a few gig of
> On Thu, May 31, 2007 at 06:29:12PM +0200, Miklos Szeredi wrote:
> > It's not just mount(8) that reads /etc/mtab, but various other
> > utilities, for example df(1). So the best solution would be if
>
> mount.nfs, mount.cifs, mount.ocfs, HAL, am-utils (amd)...
OK, I'll try to round up the peop
29 matches
Mail list logo
