On Mon, May 28, 2007 at 02:48:45PM +1000, Timothy Shimmin wrote:
I'm taking it that the FUA write will just guarantee that that
particular write has made it to disk on i/o completion
(and no write cache flush is done).
Correct. It only applies to that one write command.
jeremy
-
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 to use
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 to do
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
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
Submitter :
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
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
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 for
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 included
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 force a
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
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
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
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) {
+
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, 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
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,
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 wait
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
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
metadata
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
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, struct nfs_mount_args
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 for
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 SELinux policy; I
do
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
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
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 [EMAIL
[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 dumb to
28 matches
Mail list logo
