On Tue, May 29, 2007 at 05:01:24PM -0700, [EMAIL PROTECTED] wrote:
> On Wed, 30 May 2007, David Chinner wrote:
>
> >On Tue, May 29, 2007 at 04:03:43PM -0400, Phillip Susi wrote:
> >>David Chinner wrote:
> >>>The use of barriers in XFS assumes the commit write to be on stable
> >>>storage before it
[EMAIL PROTECTED] wrote:
> On Mon, 28 May 2007 21:54:46 EDT, Kyle Moffett said:
>
>> 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
On Tue, May 29, 2007 at 02:52:53PM +0200, Michal Piotrowski wrote:
> Hi all,
>
> Here is a list of some known regressions in 2.6.22-rc3.
>
>
> Kbuild
>
> Subject: make M=$PWD modules_install does nothing
> References : http://lkml.org/lkml/2007/5/27/190
> Submitter : Andrey Borzenkov <[EMA
On Wed, 30 May 2007 05:13:54 +0200 Nick Piggin <[EMAIL PROTECTED]> wrote:
> On Tue, May 29, 2007 at 02:19:55PM -0700, Andrew Morton wrote:
> >
> > The patch titled
> > fs: introduce write_begin, write_end, and perform_write aops
> > has been added to the -mm tree. Its filename is
> > f
On Tue, May 29, 2007 at 02:19:55PM -0700, Andrew Morton wrote:
>
> The patch titled
> fs: introduce write_begin, write_end, and perform_write aops
> has been added to the -mm tree. Its filename is
> fs-introduce-write_begin-write_end-and-perform_write-aops.patch
>
> *** Remember to use
2007/5/29, Kyle Moffett <[EMAIL PROTECTED]>:
>>> But writing policy with labels are somewhat indirect way (I mean,
>>> we need "ls -Z" or "ps -Z"). Indirect way can cause flaw so we
>>> need a lot of work that is what I wanted to tell.
>>
>> I don't really use "ls -Z" or "ps -Z" when writing SEL
On Tue, May 29, 2007 at 11:40:42AM -0400, Jeff Layton wrote:
> After spending quite a bit of time tracking down a "VFS: busy inodes
> after unmount" problem, it occurs to me that it would be nice to be
> able to force a panic when that occurs. While an oops message alone is
> not generally helpful
On Fri, May 25, 2007 at 06:25:31PM +0200, Jean noel Cordenner wrote:
> Hi,
>
> This is an update of the i_version patch.
> The i_version field is a 64bit counter that is set on every inode
> creation and that is incremented every time the inode data is modified
> (similarly to the "ctime" time-sta
On Tue, May 29, 2007 at 05:08:01PM -0400, Chuck Lever wrote:
> Karel Zak wrote:
> >On Mon, May 21, 2007 at 12:09:54PM -0400, Chuck Lever wrote:
> >>For NFSv2 and NFSv3 mount options.
> >>Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
> >
> >
> >
> >>+static int nfs_parse_options(char *raw, str
On Wed, 30 May 2007, David Chinner wrote:
On Tue, May 29, 2007 at 04:03:43PM -0400, Phillip Susi wrote:
David Chinner wrote:
The use of barriers in XFS assumes the commit write to be on stable
storage before it returns. One of the ordering guarantees that we
need is that the transaction (comm
On Tue, May 29, 2007 at 04:03:43PM -0400, Phillip Susi wrote:
> David Chinner wrote:
> >The use of barriers in XFS assumes the commit write to be on stable
> >storage before it returns. One of the ordering guarantees that we
> >need is that the transaction (commit write) is on disk before the
> >m
On May 29, 2007 12:44 -0700, Mingming Cao wrote:
> I am a little bit confused about the two patches.
>
> It appears in the ext4_expand_inode_extra_isize patch by Kalpak, there a
> new 64 bit i_fs_version field is added to ext4 inode structure for inode
> versioning support. read/store of this co
On Tue, May 29, 2007 at 11:25:42AM +0200, Stefan Bader wrote:
> doing a sort of suspend, issuing the
> barrier request, calling flush to all mapped devices and then wait for
> in-flight I/O to go to zero?
Something like that is needed for some dm targets to support barriers.
(We needn't always wa
One more vague question I had while skimming the previous version--
On Tue, May 29, 2007 at 03:54:27PM +0100, David Howells wrote:
> +static void afs_grant_locks(struct afs_vnode *vnode, struct file_lock *fl)
> +{
> + struct file_lock *p, *_p;
> +
> + list_move_tail(&fl->fl_u.afs.link, &vn
On Mon, 28 May 2007 21:54:46 EDT, Kyle Moffett said:
> Average users are not supposed to be writing security policy. To be
> honest, even average-level system administrators should not be
> writing security policy. It's OK for such sysadmins to tweak
> existing policy to give access to add
Karel Zak wrote:
On Mon, May 21, 2007 at 12:09:54PM -0400, Chuck Lever wrote:
For NFSv2 and NFSv3 mount options.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
+static int nfs_parse_options(char *raw, struct nfs_mount_args *mnt)
+{
+ char *p, *string;
+
+ if (!raw) {
+
On Mon, May 21, 2007 at 12:09:54PM -0400, Chuck Lever wrote:
> For NFSv2 and NFSv3 mount options.
> Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
> +static int nfs_parse_options(char *raw, struct nfs_mount_args *mnt)
> +{
> + char *p, *string;
> +
> + if (!raw) {
> + dp
On Tue, May 29, 2007 at 10:34:41AM +0100, David Howells wrote:
> I'll need to test the upgrade/downgrade case. I don't know whether the AFS
> server supports that. If it doesn't, I can emulate downgrade, but not upgrade
> - not unless I only ever ask it for exclusive locks.
>
> Lock upgrading is
David Chinner wrote:
Sounds good to me, but how do we test to see if the underlying
device supports barriers? Do we just assume that they do and
only change behaviour if -o nobarrier is specified in the mount
options?
The idea is that ALL block devices will support barriers; if the
underlying
Neil Brown wrote:
md/dm modules could keep count of requests as has been suggested
(though that would be a fairly big change for raid0 as it currently
doesn't know when a request completes - bi_endio goes directly to the
filesystem).
Are you sure? I believe that dm handles bi_endio becaus
On Tue, 29 May 2007 23:38:13 +0400
Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> On Tue, May 29, 2007 at 11:40:42AM -0400, Jeff Layton wrote:
> > After spending quite a bit of time tracking down a "VFS: busy inodes
> > after unmount" problem, it occurs to me that it would be nice to be
> > able to
On Fri, 2007-05-25 at 18:25 +0200, Jean noel Cordenner wrote:
> The patch is on top of the ext4 tree:
> http://repo.or.cz/w/ext4-patch-queue.git
>
> In this part, the i_version counter is stored into 2 32bit fields of
> the ext4_inode structure osd1.linux1.l_i_version and i_version_hi.
>
> I incl
On Tue, May 29, 2007 at 11:40:42AM -0400, Jeff Layton wrote:
> After spending quite a bit of time tracking down a "VFS: busy inodes
> after unmount" problem, it occurs to me that it would be nice to be
> able to force a panic when that occurs. While an oops message alone is
> not generally helpful
After spending quite a bit of time tracking down a "VFS: busy inodes
after unmount" problem, it occurs to me that it would be nice to be
able to force a panic when that occurs. While an oops message alone is
not generally helpful for tracking down this sort of problem,
collecting and analyzing a co
Implement file locking for AFS.
[try #2]:
(*) Start the lock manager thread under a mutex to avoid a race.
(*) Made the locking non-fair: New readlocks will jump pending writelocks if
there's a readlock currently granted on a file. This makes the behaviour
similar to Linux's VFS loc
On Tue, May 29, 2007 at 04:34:59PM +0200, Jan Kara wrote:
> On Tue 29-05-07 14:52:53, Michal Piotrowski wrote:
> > Here is a list of some known regressions in 2.6.22-rc3.
> >
> > Subject: Oops in dentry_iput with 2.6.22-rc2 on AMD64
> > References : http://lkml.org/lkml/2007/5/22/4
> > Submitt
Hi,
On Tue 29-05-07 14:52:53, Michal Piotrowski wrote:
> Here is a list of some known regressions in 2.6.22-rc3.
>
> Feel free to add new regressions/remove fixed etc.
> http://kernelnewbies.org/known_regressions
>
> File systems
>
> Subject: Oops in dentry_iput with 2.6.22-rc2 on AMD6
Hi all,
Here is a list of some known regressions in 2.6.22-rc3.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
Unclassified
Subject: long freezes on thinkpad t60
References : http://lkml.org/lkml/2007/5/24/100
Submitter : Miklos Szeredi <[EM
J. Bruce Fields <[EMAIL PROTECTED]> wrote:
> > At the moment, yes. Don't the POSIX and flock lock-handling routines in the
> > kernel normally do that anyway?
>
> No, they'd upgrade in that case.
I just checked. The OpenAFS server supports neither lock upgrading nor lock
downgrading. Attempts
J. Bruce Fields <[EMAIL PROTECTED]> wrote:
> You can contrive examples of applications that would be correct given
> the standard fcntl behavior, but that would deadlock on a system that
> didn't allow read locks to jump the queue in the above situation.
Yes, but you can also contrive starvation
2007/5/28, Alasdair G Kergon <[EMAIL PROTECTED]>:
On Mon, May 28, 2007 at 11:30:32AM +1000, Neil Brown wrote:
> 1/ A BIO_RW_BARRIER request should never fail with -EOPNOTSUP.
The device-mapper position has always been that we require
> a zero-length BIO_RW_BARRIER
(i.e. containing no data to
> 2007/5/25, Neil Brown <[EMAIL PROTECTED]>:
> BIO_RW_FAILFAST: means low-level driver shouldn't do much (or no)
> error recovery. Mainly used by mutlipath targets to avoid long SCSI
> recovery. This should just be propagated when passing requests on.
Is it "much" or "no"?
Would it be reasonable
32 matches
Mail list logo
