On Mon, 19 February 2007 21:06:33 -0600, Dave Kleikamp wrote:
You've obviously given this a lot more thought that I have, but this
sounds like something that has possibilities. You couldn't implement
your own drop_inode method that does better locking against the garbage
collector?
Bloody
On Tue, Feb 20, 2007 at 10:46:51AM -0500, Robert Rappaport wrote:
We also have the same problem with leases, since we're using leases to
implement NFSv4 delegations. There's a simple-minded patch here:
Hi,
I'm trying to get an nfs server setup on our embedded 2.6.19 kernel
system. I've chosen to use the kernel nfsd module,
and am using the latest nfs-utils.
It all starts running, but I get this:
mount -t nfs 127.0.0.1:/etc /tmp/try
mount: 127.0.0.1:/etc failed, reason given by server:
On Tue, Feb 20, 2007 at 10:46:51AM -0500, Robert Rappaport wrote:
Thank you both for your helpful replies. In particular, the addition
of the calls to file system specific functions in routines,
fcntl_setlease() and break_lease(), as well as the modifications to
the file_operations and
Bruce,
After looking more carefully at your changes, I have a question. Why
didn't you modify the linux kernel routine, setlease(), so that it
would either call f_op-set_lease() or __setlease()? Instead you
created a new routine, nfs4_setlease(), and you modified the previous
calls to
On Tue, 2007-02-20 at 02:31 -0500, Hank Leininger wrote:
Is there anything provided by the kernel that would let you see the
current offset of an existing filehandle?
Sometimes when processing a very large file (grepping a log, bzip2'ing
or gpg'ing a file, or whatever), I'd really like to
On Tue, 2007-02-20 at 02:31 -0500, Hank Leininger wrote:
Is there anything provided by the kernel that would let you see the
current offset of an existing filehandle?
Sometimes when processing a very large file (grepping a log, bzip2'ing
or gpg'ing a file, or whatever), I'd really like
On Tue, Feb 20, 2007 at 10:46:51AM -0500, Robert Rappaport wrote:
We did an experimental distributed lease implementation in gfs(1) a while
ago. It worked, but was so extremely expensive that there was no point in
considering it seriously. The problem is that _every_ open and close of
every
I wrote:
On Tue, Feb 20, 2007 at 10:46:51AM -0500, Robert Rappaport wrote:
We did an experimental distributed lease implementation in gfs(1) a while
(Sorry for the misattribution, it was David Tiegland that said that. I'm
having some mail troubles)--b.
-
To unsubscribe from this list: send
Robert Rappaport [EMAIL PROTECTED] said:
After looking more carefully at your changes, I have a question. Why
didn't you modify the linux kernel routine, setlease(), so that it
would either call f_op-set_lease() or __setlease()? Instead you
created a new routine, nfs4_setlease(), and you
On Tue, Feb 20, 2007 at 03:51:54PM -0500, [EMAIL PROTECTED] wrote:
On Tue, Feb 20, 2007 at 10:46:51AM -0500, Robert Rappaport wrote:
We did an experimental distributed lease implementation in gfs(1) a while
ago. It worked, but was so extremely expensive that there was no point in
On Thu, Feb 15, 2007 at 09:20:21AM -0500, Theodore Tso wrote:
It's actually not the case that fsck will complete the truncate for
file A. The problem is that while e2fsck is processing indirect
blocks in pass 1, the block which is marked as file A's indirect block
(but which actually
On Tue, Feb 20, 2007 at 01:30:25PM -0800, Junfeng Yang wrote:
On 2/20/07, Valerie Henson [EMAIL PROTECTED] wrote:
Google. (GoogleFS runs on top of ext2.)
It's surprising to know that... I guess they reply on GoogleFS's own
replication and checksumming for consistency.
Yep, they
On 2/20/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Robert Rappaport [EMAIL PROTECTED] said:
After looking more carefully at your changes, I have a question. Why
didn't you modify the linux kernel routine, setlease(), so that it
would either call f_op-set_lease() or __setlease()? Instead
In message [EMAIL PROTECTED], Valerie Henson writes:
On Thu, Feb 15, 2007 at 09:20:21AM -0500, Theodore Tso wrote:
And POSIX also states that sync() is only required to schedule the
writes, but may return before the actual writing is done. Looks like
One more reason to form a group to
On Tue, 2007-02-20 at 21:39 +, Valerie Henson wrote:
On Tue, Feb 20, 2007 at 01:30:25PM -0800, Junfeng Yang wrote:
On 2/20/07, Valerie Henson [EMAIL PROTECTED] wrote:
Google. (GoogleFS runs on top of ext2.)
It's surprising to know that... I guess they reply on GoogleFS's own
On Tuesday February 20, [EMAIL PROTECTED] wrote:
Hi,
I'm trying to get an nfs server setup on our embedded 2.6.19 kernel
system. I've chosen to use the kernel nfsd module,
and am using the latest nfs-utils.
It all starts running, but I get this:
mount -t nfs 127.0.0.1:/etc /tmp/try
I've been working on the read-only bind mount patches, and
one of their requirements is that we track the number of
writers to a particular filesystem. This allows us to
quickly determine whether it is OK to make rw-ro
transitions.
It was noted that the previous approach of using a spinlock
to
Most mnt_want/drop_write() pairs are really close in
the code; they aren't held for very long. So, in
practice is hard to get bounced between cpus between
when you mnt_want_write() and mnt_drop_write().
The exception to this is the pair in may_open() and
__fput(). Between those two it is
It is a bug to set a page dirty if it is not uptodate unless it has
buffers. If the page has buffers, then the page may be dirty (some buffers
dirty) but not uptodate (some buffers not uptodate). The exception to this
rule is if the set_page_dirty caller is racing with truncate or invalidate.
A
20 matches
Mail list logo
