Hi,
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
default_backing_dev_info.
With my recent per bdi dirty limit
Hi Andrew.
On Fri, Oct 26, 2007 at 01:55:38PM -0700, Andrew Morton ([EMAIL PROTECTED])
wrote:
I'm pleased to announce sixth release of the distributed storage
subsystem, which allows to form a storage on top of remote and local
nodes, which in turn can be exported to another storage as a
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
Hi,
-bmap is ugly and horrible! If you have to do this at the very least
please cause -bmap64 to be able to return error values in case the
file system failed to get the information or indeed such information
does not exist as is the case for compressed and encrypted files for
example
On 10/27/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
Hi,
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
On Sat, 2007-10-27 at 16:02 -0500, Steve French wrote:
On 10/27/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
Hi,
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
On Sat, 2007-10-27 at 23:30 +0200, Peter Zijlstra wrote:
On Sat, 2007-10-27 at 16:02 -0500, Steve French wrote:
On 10/27/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
Hi,
I had me a little look at bdi usage in networked filesystems.
NFS, CIFS, (smbfs), AFS, CODA and NCP
And
On Sat, 27 Oct 2007, Anton Altaparmakov wrote:
And another of my pet peeves with -bmap is that it uses 0 to mean sparse
which causes a conflict on NTFS at least as block zero is part of the $Boot
system file so it is a real, valid block... NTFS uses -1 to denote sparse
blocks internally.
In message [EMAIL PROTECTED], Christoph Hellwig writes:
On Mon, Oct 22, 2007 at 08:48:04PM -0400, Erez Zadok wrote:
Why? Are you concerned that the security policy may change after a module
is loaded?
No, it's a matter of proper layering. We generally don't want modules
like stackabke
This series of three proposed patches changes fs/ioctl.c and Unionfs as
follows. This series is against v2.6.24-rc1-192-gef49c32.
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)
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
Mike Waychison wrote:
The following series is meant to clean up FIBMAP paths with the eventual goal
of allowing users to be able to FIBMAP their data.
Keep in mind FIBMAP is currently extremely expensive on some
filesystems, e.g. ext3. Therefore, additional filesystem-level work
would have
12 matches
Mail list logo
