On Sat, Oct 27, 2007 at 11:34:26AM +0200, Peter Zijlstra wrote:
I had me a little look at bdi usage in networked filesystems.
NFS, CIFS, (smbfs), AFS, CODA and NCP
And of those, NFS is the only one that I could find that creates
backing_dev_info structures. The rest seems to fall back to
op.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
Coda part looks fine to me. Couldn't test it beyond 'it compiles and
doesn't oops', because our userspace client unconditionally strips
setuid/setgid bits anyways.
Acked-by: Jan Harkes [EMAIL PROTECTED]
-
To unsubscribe from this list: send
On Fri, Jul 20, 2007 at 06:38:07AM +0100, Al Viro wrote:
On Fri, Jul 20, 2007 at 12:10:00AM -0400, Jan Harkes wrote:
I will try to find a clean way to block the close syscall until fput
drops the last reference. However I realize that such an implementation
would not be acceptable for other
to pick some close as a 'last-close' and delay it until all
other references have been destroyed.
The CODA_STORE/CODA_RELEASE upcall combination is clearly a broken design, and
it is better to remove it completely.
Signed-off-by: Jan Harkes [EMAIL PROTECTED]
Cc: Christoph Hellwig [EMAIL PROTECTED
On Thu, Jul 19, 2007 at 11:45:08PM +0200, Christoph Hellwig wrote:
-release is the proper way to detect the last close of a file,
file_count should never be used in filesystems.
Has been tried, the problem with that once -release is called it is too
late to pass the the error back to close(2).
On Fri, Jul 20, 2007 at 01:53:16AM +0100, Al Viro wrote:
On Fri, Jul 20, 2007 at 10:45:34AM +1000, David Chinner wrote:
On Thu, Jul 19, 2007 at 06:16:00PM -0400, Jan Harkes wrote:
On Thu, Jul 19, 2007 at 11:45:08PM +0200, Christoph Hellwig wrote:
-release is the proper way to detect
coda_flush. This
avoids the race condition described by Al Viro where we may never see
the file_count drop to 0 in -flush, in which case userspace is never
notified that a writeback should occur.
Signed-off-by: Jan Harkes [EMAIL PROTECTED]
---
Going from here I can fix the problem in several ways
On Tue, Jun 19, 2007 at 03:13:33PM -0700, H. Peter Anvin wrote:
[EMAIL PROTECTED] wrote:
the only trouble I ever had with the .snapshot approach is when tar or
find would decend down into the .snapshot when I didn't really intend
for it to do so.
Netapp optionally made .snapshot
On Sat, Jun 16, 2007 at 02:03:49PM -0600, Jeffrey V. Merkey wrote:
Jan Harkes wrote:
implementation, just a high level description. Finally advising anyone
(who is not an actual patent lawyer that could correctly interpret the
language and scope of a patent) to go search out patents seems
Since you decide to publically respond to a private email, but not only
you did not 'discuss' anything I wrote and in fact cut out most of the
useful information in my reply I guess I will have to repeat my
observations.
Once I send out this email, I'll just add you to my friendly killfile
(as
On Mon, Jan 01, 2007 at 11:47:06PM +0100, Mikulas Patocka wrote:
Anyway, cp -a is not the only application that wants to do hardlink
detection.
I tested programs for ino_t collision (I intentionally injected it) and
found that CP from coreutils 6.7 fails to copy directories but displays
On Wed, Dec 20, 2006 at 12:44:42PM +0100, Miklos Szeredi wrote:
The stat64.st_ino field is 64bit, so AFAICS you'd only need to extend
the kstat.ino field to 64bit and fix those filesystems to fill in
kstat correctly.
Coda actually uses 128-bit file identifiers internally, so 64-bits
really
On Tue, Mar 27, 2001 at 09:15:08AM -0800, LA Walsh wrote:
Now lets look at the sites want to process terabytes of
data -- perhaps files systems up into the Pentabyte range. Often I
can see these being large multi-node (think 16-1024 clusters as
are in use today for large
13 matches
Mail list logo
