On 10/30/07, Greg Banks [EMAIL PROTECTED] wrote:
BIO_HINT_RELEASE
The bio's block extent is no longer in use by the filesystem
and will not be read in the future. Any storage used to back
the extent may be released without any threat to filesystem
or data integrity.
I'd
On Sun, Oct 28, 2007 at 02:05:16PM -0400, Erez Zadok wrote:
Sure. I assume you mean an internal function to encapsulate the entire case
statement's code, one for each of the FIO* cases.
Yes.
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to
On Sun, Oct 28, 2007 at 07:57:47PM -0700, Daniel Phillips wrote:
On 10/28/07, Christoph Hellwig [EMAIL PROTECTED] wrote:
While you're at it, it's probably worth splitting this out into
a small helper function.
Why? Is the same pattern called from more than one place?
Becauase it's a lot
On Sun, Oct 28, 2007 at 08:40:56PM -0400, Erez Zadok wrote:
+/**
+ * vfs_ioctl - call filesystem specific ioctl methods
+ *
+ * @filp: [in] open file to invoke ioctl method on
+ * @cmd: [in] ioctl command to execute
+ * @arg: [in/out] command-specific argument for ioctl
I've never
+static int __ioctl_fibmap(struct file *filp, int __user *p)
I'd say kill the __ prefix for all the functions you're adding.
+static int __ioctl_fionbio(struct file *filp, unsigned long arg)
+static int __ioctl_fioasync(unsigned int fd, struct file *filp,
+ unsigned
On Tuesday 30 October 2007, Dongjun Shin wrote:
There is an ongoing discussion about adding 'Trim' ATA command for notifying
the drive about the deleted blocks.
http://www.t13.org/Documents/UploadedDocuments/docs2007/e07154r3-Data_Set_Management_Proposal_for_ATA-ACS2.pdf
This is especially
On 10/30/07, Arnd Bergmann [EMAIL PROTECTED] wrote:
This make me curious, why would t13 want to invent a new command when
there is already the erase command from CFA?
It's not exactly the same, but close enough that the proposed BIO_HINT_RELEASE
should probably be mapped to CFA_ERASE (0xc0)
On 10/30/07, Arnd Bergmann [EMAIL PROTECTED] wrote:
Not sure. Why shouldn't you be able to reorder the hints provided that
they don't overlap with read/write bios for the same block?
You're right. The bios can be reordered if they don't overlap with hint.
-
To unsubscribe from this list: send
On Tue, 30 October 2007 18:35:08 +0900, Dongjun Shin wrote:
On 10/30/07, Greg Banks [EMAIL PROTECTED] wrote:
BIO_HINT_RELEASE
The bio's block extent is no longer in use by the filesystem
and will not be read in the future. Any storage used to back
the extent may be released
From: J. Bruce Fields [EMAIL PROTECTED]
It's currently possible to send posix_locks_deadlock() into an infinite
loop (under the BKL).
For now, fix this just by bailing out after a few iterations. We may
want to fix this in a way that better clarifies the semantics of
deadlock detection. But
On Tue, 30 Oct 2007 09:56:53 + Christoph Hellwig wrote:
On Sun, Oct 28, 2007 at 08:40:56PM -0400, Erez Zadok wrote:
+/**
+ * vfs_ioctl - call filesystem specific ioctl methods
+ *
+ * @filp: [in] open file to invoke ioctl method on
+ * @cmd: [in] ioctl command to execute
On Tue, 30 Oct 2007 11:20:02 -0400
J. Bruce Fields [EMAIL PROTECTED] wrote:
From: J. Bruce Fields [EMAIL PROTECTED]
It's currently possible to send posix_locks_deadlock() into an infinite
loop (under the BKL).
For now, fix this just by bailing out after a few iterations. We may
want to
On Tue, 30 October 2007 23:19:48 +0900, Dongjun Shin wrote:
On 10/30/07, Arnd Bergmann [EMAIL PROTECTED] wrote:
Not sure. Why shouldn't you be able to reorder the hints provided that
they don't overlap with read/write bios for the same block?
You're right. The bios can be reordered if
On Mon, Oct 29, 2007 at 08:06:04AM +, Alan Cox wrote:
On Sun, 28 Oct 2007 13:43:21 -0400
J. Bruce Fields [EMAIL PROTECTED] wrote:
From: J. Bruce Fields [EMAIL PROTECTED]
We currently attempt to return -EDEALK to blocking fcntl() file locking
requests that would create a cycle in
On Tuesday 30 October 2007, Jörn Engel wrote:
On Tue, 30 October 2007 23:19:48 +0900, Dongjun Shin wrote:
On 10/30/07, Arnd Bergmann [EMAIL PROTECTED] wrote:
Not sure. Why shouldn't you be able to reorder the hints provided that
they don't overlap with read/write bios for the same
On Tue, 30 Oct 2007 17:14:36 + Christoph Hellwig wrote:
On Tue, Oct 30, 2007 at 08:22:40AM -0700, Randy Dunlap wrote:
They are just treated as part of the parameter explanation text.
I don't see any problem with them.
Well, it's completely inconsistant with any other kerneldoc..
Hi,
While testing hotplug memory remove, I ran into this issue. Given a
range of pages hotplug memory remove tries to migrate those pages.
migrate_pages() keeps failing to migrate pages containing pagecache
pages for reiserfs files. I noticed that reiserfs doesn't have
-migratepage() ops. So,
In message [EMAIL PROTECTED], Christoph Hellwig writes:
On Tue, Oct 30, 2007 at 08:22:40AM -0700, Randy Dunlap wrote:
They are just treated as part of the parameter explanation text.
I don't see any problem with them.
Well, it's completely inconsistant with any other kerneldoc..
If it
BTW, what's the origin of this oddity in fs/ioctl.c:
#ifdef __sparc__
/* SunOS compatibility item. */
if (O_NONBLOCK != O_NDELAY)
flag |= O_NDELAY;
#endif
It seems rather odd to have architecture-specific code in the VFS, no?
Erez.
-
To unsubscribe from this
On Tue, 30 Oct 2007 10:27:04 -0800
Badari Pulavarty [EMAIL PROTECTED] wrote:
Hi,
While testing hotplug memory remove, I ran into this issue. Given a
range of pages hotplug memory remove tries to migrate those pages.
migrate_pages() keeps failing to migrate pages containing pagecache
On Tue, Oct 30, 2007 at 01:49:48PM -0400, Erez Zadok wrote:
BTW, what's the origin of this oddity in fs/ioctl.c:
#ifdef __sparc__
/* SunOS compatibility item. */
if (O_NONBLOCK != O_NDELAY)
flag |= O_NDELAY;
#endif
It seems rather odd to have
This series of 4 proposed patches (take 3) changes fs/ioctl.c and Unionfs as
follows. This series is against v2.6.24-rc1-423-g97855b4.
Patch 1: just applies coding standards to fs/ioctl.c (while I'm at it, I
figured it's worth cleaning VFS files one at a time).
Patch 2: does two things:
(a)
Signed-off-by: Erez Zadok [EMAIL PROTECTED]
---
fs/unionfs/commonfops.c | 36 ++--
1 files changed, 6 insertions(+), 30 deletions(-)
diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
index 7654bcb..c99b519 100644
--- a/fs/unionfs/commonfops.c
+++
Signed-off-by: Erez Zadok [EMAIL PROTECTED]
---
fs/ioctl.c | 164 +++-
1 files changed, 84 insertions(+), 80 deletions(-)
diff --git a/fs/ioctl.c b/fs/ioctl.c
index c2a773e..652cacf 100644
--- a/fs/ioctl.c
+++ b/fs/ioctl.c
@@ -12,8 +12,8
Rename old vfs_ioctl to do_ioctl, because the comment above it clearly
indicates that it is an internal function not to be exported to modules;
therefore it should have a more traditional do_XXX name. The new do_ioctl
is exported in fs.h but not to modules.
Rename the old do_ioctl to vfs_ioctl
Signed-off-by: Erez Zadok [EMAIL PROTECTED]
---
fs/ioctl.c | 129 +++-
1 files changed, 75 insertions(+), 54 deletions(-)
diff --git a/fs/ioctl.c b/fs/ioctl.c
index 1ab7b7d..cd8c1a3 100644
--- a/fs/ioctl.c
+++ b/fs/ioctl.c
@@ -53,32 +53,34
On Tue, 2007-10-30 at 13:54 -0400, Chris Mason wrote:
On Tue, 30 Oct 2007 10:27:04 -0800
Badari Pulavarty [EMAIL PROTECTED] wrote:
Hi,
While testing hotplug memory remove, I ran into this issue. Given a
range of pages hotplug memory remove tries to migrate those pages.
On Tue, 30 Oct 2007 13:54:05 -0800
Badari Pulavarty [EMAIL PROTECTED] wrote:
On Tue, 2007-10-30 at 13:54 -0400, Chris Mason wrote:
On Tue, 30 Oct 2007 10:27:04 -0800
Badari Pulavarty [EMAIL PROTECTED] wrote:
Hi,
While testing hotplug memory remove, I ran into this issue. Given
On Tue, 30 Oct 2007 15:39:55 -0400
Erez Zadok [EMAIL PROTECTED] wrote:
This series of 4 proposed patches (take 3) changes fs/ioctl.c and Unionfs as
follows.
The problem is of course that you need these in your tree for ongoing
development, but 2.6.25 is months away. They look OK to me so I
Chris Mason wrote:
On Tue, 30 Oct 2007 13:54:05 -0800
Badari Pulavarty [EMAIL PROTECTED] wrote:
On Tue, 2007-10-30 at 13:54 -0400, Chris Mason wrote:
On Tue, 30 Oct 2007 10:27:04 -0800
Badari Pulavarty [EMAIL PROTECTED] wrote:
Hi,
While testing hotplug memory remove, I ran
On 10/31/07, Arnd Bergmann [EMAIL PROTECTED] wrote:
On Tuesday 30 October 2007, Jörn Engel wrote:
On Tue, 30 October 2007 23:19:48 +0900, Dongjun Shin wrote:
On 10/30/07, Arnd Bergmann [EMAIL PROTECTED] wrote:
Not sure. Why shouldn't you be able to reorder the hints provided that
On Tue, Oct 30, 2007 at 03:16:06PM +1100, Neil Brown wrote:
On Tuesday October 30, [EMAIL PROTECTED] wrote:
BIO_HINT_RELEASE
The bio's block extent is no longer in use by the filesystem
and will not be read in the future. Any storage used to back
the extent may be released
On Tue, 2007-10-30 at 16:08 -0700, Badari wrote:
Chris Mason wrote:
On Tue, 30 Oct 2007 13:54:05 -0800
[cut]
The easy way to narrow our search is to try without data=ordered, it is
certainly complicating things.
I can try that, its my root filesystem :(
You meant to write can't?
On Tue, Oct 30, 2007 at 06:35:08PM +0900, Dongjun Shin wrote:
On 10/30/07, Greg Banks [EMAIL PROTECTED] wrote:
BIO_HINT_RELEASE
The bio's block extent is no longer in use by the filesystem
and will not be read in the future. Any storage used to back
the extent may be
On Wed, Oct 31, 2007 at 10:56:52AM +1100, David Chinner wrote:
On Tue, Oct 30, 2007 at 03:16:06PM +1100, Neil Brown wrote:
On Tuesday October 30, [EMAIL PROTECTED] wrote:
BIO_HINT_RELEASE
The bio's block extent is no longer in use by the filesystem
and will not be read in the
35 matches
Mail list logo
