This account is now no longer in use.
Please comtact [EMAIL PROTECTED] instead.
Please remove .spa.m from the above address when contacting me.
Many thanks,
64Apocalypse Admin.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PR
On Saturday 30 June 2007 11:13, Christoph Hellwig wrote:
> We need something like this, but I don't quite like the way you've done
> it. First the name is wrong, it's not a nameidata anymore but a lookup
> intent, so it should be named that way, struct lookup_intent.
Sure, that name was pretty ra
The reason that cifs switched from wait_for_completion to the kthread
call to cifs_demultiplex_thread in the first place is because without
use of kthread it won't work with a linux-vserver. See the thread:
http://marc.info/?l=linux-cifs-client&m=117552761703381&w=2
If we take out the kthread
Christoph Hellwig wrote:
The following additional fields are appended to each record
in /proc/mounts
NACK. Adding anything to the format will confuse the hell out of
existing parsers. We really want something like your /proc//mounts_new,
except mounts_new should have a better name (/proc//ns
This e-mail alias is unmonitored
For questions or general inquiries related to the Winchester web site please
visit the below URL:
http://www.winchester.com/contactus/contactus.aspx
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROT
Christoph Hellwig wrote:
On Tue, Jun 26, 2007 at 12:35:09PM +1000, Nick Piggin wrote:
I'd like to see you there, so I hope we can find a date that most
people are happy with. I'll try to start working that out after we
have a rough idea of who's interested.
Do we have any data preferen
The address you used is no longer in use. Please use [EMAIL PROTECTED] instead.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Larry has retired from Wolff Shoe.
If your email was business related and you need to contact Wolff Shoe, please
email Tim Rosheim at 636-343-7770.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
On Sat, 30 Jun 2007 09:42:09 +0100
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 25, 2007 at 05:25:00PM -0500, Steve French wrote:
> > Jeff,
> > Not seeing any objections to your revised approach (to not allowing
> > signals for cifsd kernel thread), I just merged something similar to
On Sat, Jun 30, 2007 at 07:10:27AM -0400, Jeff Garzik wrote:
> >Not really, the current behaviour is a bug. And it's not actually buffer
> >layer specific - XFS now has a fix for that bug and it's generic enough
> >that everyone could use it.
>
> I'm not sure I follow. If you require block alloc
Christoph Hellwig wrote:
On Sat, Jun 23, 2007 at 11:07:54PM -0400, Jeff Garzik wrote:
- In line with the above item, filesystem block allocation is performed
before a page is dirtied. In the buffer layer, mmap writes can dirty a
page with no backing blocks which is a problem if the filesystem
Warning ahead: I've only briefly skipped over the pages so the comments
in the mail are very highlevel.
On Sun, Jun 24, 2007 at 03:45:28AM +0200, Nick Piggin wrote:
> fsblock is a rewrite of the "buffer layer" (ding dong the witch is
> dead), which I have been working on, on and off and is now at
On Mon, Jun 25, 2007 at 08:25:21AM -0400, Chris Mason wrote:
> > write_begin/write_end is a step in that direction (and it helps
> > OCFS and GFS quite a bit). I think there is also not much reason
> > for writepage sites to require the page to lock the page and clear
> > the dirty bit themselves (
> "Christoph" == Christoph Hellwig <[EMAIL PROTECTED]> writes:
Christoph> On Tue, Jun 26, 2007 at 10:07:24AM -0700, Jared Hulbert
Christoph> wrote:
>> If you have a large array of a non-volatile semi-writeable memory
>> such as a highspeed NOR Flash or some of the similar emerging
>> technolog
On Sat, Jun 23, 2007 at 11:07:54PM -0400, Jeff Garzik wrote:
> >- In line with the above item, filesystem block allocation is performed
> > before a page is dirtied. In the buffer layer, mmap writes can dirty a
> > page with no backing blocks which is a problem if the filesystem is
> > ENOSPC (p
On Tue, Jun 26, 2007 at 08:26:50AM -0400, Chris Mason wrote:
> Since we're testing new code, I would just leave the blkdev address
> space alone. If a filesystem wants to use fsblocks, they allocate a new
> inode during mount, stuff it into their private super block (or in the
> generic super), an
On Tue, Jun 26, 2007 at 12:34:26PM +1000, Nick Piggin wrote:
> That would require a new inode and address_space for the fsblock
> type blockdev pagecache, wouldn't it?
Yes. That's easily possible, XFS already does it for it's own
buffer cache.
-
To unsubscribe from this list: send the line "unsu
On Wed, Jun 27, 2007 at 11:36:57PM +1000, David Chinner wrote:
> > This
> > would seem to be the only impediment from using fallocated files
> > for swap files. Maybe if FIEMAP was used by mkswap to get an
> > "UNWRITTEN" flag back instead of "HOLE" it wouldn't be a problem.
>
> Probably. If we t
On Tue, Jun 26, 2007 at 04:02:47PM +0530, Amit K. Arora wrote:
> > Can you clarify - what is the current behaviour when ENOSPC (or some other
> > error) is hit? Does it keep the current fallocate() or does it free it?
>
> Currently it is left on the file system implementation. In ext4, we do
> no
On Thu, Jun 14, 2007 at 03:14:58AM -0600, Andreas Dilger wrote:
> I suppose it might be a bit late in the game to add a "goal"
> parameter and e.g. FA_FL_REQUIRE_GOAL, FA_FL_NEAR_GOAL, etc to make
> the API more suitable for XFS? The goal could be a single __u64, or
> a struct with e.g. __u64 byte
On Sat, Jun 30, 2007 at 06:02:44AM -0400, [EMAIL PROTECTED] wrote:
> You need either a block translation layer, or a (swap) filesystem that
> understands flash peculiarities in order to make such a thing work.
> The standard Linux swap format will not work.
Yes, it basically needs an ftl.
-
To
On Sat, Jun 23, 2007 at 09:52:46AM -0700, Andrew Morton wrote:
> Doesn't selinux do some of this?
No.
> My overall reaction: owch. There's a ton of tricksy code here and great
> potential for us to accidentally break it in the future by forgetting a
> mnt_may_write() as the kernel evolves. And
On Mon, Jun 25, 2007 at 03:00:15PM -0700, Ram Pai wrote:
> Please check if the following modified patch meets the requirements.
>
> It augments /proc/mount with additional information to
> (1) disambiguate bind mounts with subroot information.
> (2) display shared-subtree information u
On Wed, Jun 20, 2007 at 01:44:52PM -0400, Trond Myklebust wrote:
> > Which is exactly that problem this tries to solve. Once you have
> > union mounts you'll have a single open file descriptor for multiple
> > actual directories. Beause of that you can't simply attach to the
> > state to the str
On Mon, Jun 25, 2007 at 08:19:52AM -0700, Dave Hansen wrote:
> > Should we just take the calls outside the switch statement?
>
> Yeah, that's much better. I assume we don't care whether we're getting
> -EROFS or -EPERM/-EINVAL for the S_IFDIR and default cases?
We need to keep the exact error r
On Mon, Jun 25, 2007 at 11:32:08AM -0700, Dave Hansen wrote:
> How does this look?
>
> - if (IS_RDONLY(inode))
> + /*
> +* Ideally, we want to guarantee that 'f_vfsmnt'
> +* is non-NULL here. But, NFS exports need to
> +* be fixed up before we can do that. So,
On Mon, Jun 25, 2007 at 11:27:25AM -0700, Dave Hansen wrote:
> I've got this in the next set:
>
> -
> - if(IS_RDONLY(nd.dentry->d_inode))
> + /*
> +* This is a rare case where using __mnt_is_readonly()
> +* is OK without a mnt_want/drop_write() pair. Since
> +*
On Mon, Jun 25, 2007 at 10:32:43AM -0700, Dave Hansen wrote:
> Looks like I had them againt plain 2.6.21. That'll do it.
>
> I'll rebase and test with Greg's tree.
Can you send it out ASAP? I want to do the indepth review so we can
get this in ASAP and kill the get_empty_filp export eventually.
On Thu, Jun 21, 2007 at 12:01:43PM -0700, Mark Fasheh wrote:
> Plug ocfs2 into the ->fallocate() callback. We only support FA_ALLOCATE for
> now - FA_DEALLOCATE will come later.
Btw, it seems like ocfs implements the xfs preallocation ioctls. What
would people thing about moving those up to work
On Tue, Jun 26, 2007 at 10:07:24AM -0700, Jared Hulbert wrote:
> If you have a large array of a non-volatile semi-writeable memory such
> as a highspeed NOR Flash or some of the similar emerging technologies
> in a system. It would be useful to use that memory as an extension of
> RAM. One of the
On Tue, Jun 26, 2007 at 12:35:09PM +1000, Nick Piggin wrote:
> I'd like to see you there, so I hope we can find a date that most
> people are happy with. I'll try to start working that out after we
> have a rough idea of who's interested.
Do we have any data preferences yet?
-
To unsubscribe from
On Mon, Jun 25, 2007 at 06:42:44PM +0200, Jan Kara wrote:
> Hi,
>
> I came across the following question: What is the proper locking for
> using i_flags? I've noticed i_flags are read freely without any lock.
> The modifications I've seen e.g. in ext3 were done under i_mutex. Is this
> right?
On Tue, Jun 26, 2007 at 04:07:57PM -0700, [EMAIL PROTECTED] wrote:
> This is needed for computing pathnames in the AppArmor LSM.
Please see the various per-mountpoint r/o thread that NACKed all the
vfsmount additions and have the rationale for it.
-
To unsubscribe from this list: send the line "u
On Fri, Jun 29, 2007 at 03:21:29PM -0400, J. Bruce Fields wrote:
> +static int gfs2_setlease(struct file *file, long arg, struct file_lock **fl)
> +{
> + struct gfs2_sbd *sdp = GFS2_SB(file->f_mapping->host);
> + int ret = -EOPNOTSUPP;
> +
> + if (sdp->sd_args.ar_localflocks) {
> +
On Fri, Jun 29, 2007 at 03:21:26PM -0400, J. Bruce Fields wrote:
> From: J. Bruce Fields <[EMAIL PROTECTED]>
>
> Currently leases are only kept locally, so there's no way for a distributed
> filesystem to enforce them against multiple clients. We're particularly
> interested in the case of nfsd e
On Fri, Jun 29, 2007 at 03:21:30PM -0400, J. Bruce Fields wrote:
> From: J. Bruce Fields <[EMAIL PROTECTED]>
>
> As Peter Staubach says elsewhere
> (http://marc.info/?l=linux-kernel&m=118113649526444&w=2):
>
> > The problem is that some file system such as NFSv2 and NFSv3 do
> > not have sufficie
On Fri, Jun 29, 2007 at 03:21:28PM -0400, J. Bruce Fields wrote:
> From: J. Bruce Fields <[EMAIL PROTECTED]>
>
> Bring lease exports into line with conventions for posix locks:
> setlease() should be exported so filesystems can use it to implement
> their lease methods.
>
On Fri, Jun 29, 2007 at 03:21:27PM -0400, J. Bruce Fields wrote:
> From: J. Bruce Fields <[EMAIL PROTECTED]>
>
> We've been using the convention that vfs_foo is the function that calls
> a filesystem-specific foo method if it exists, or falls back on a
> generic method if it doesn't.
>
> So renam
On Fri, Jun 29, 2007 at 03:21:25PM -0400, J. Bruce Fields wrote:
> From: J. Bruce Fields <[EMAIL PROTECTED]>
>
> Share more code between setlease (used by nfsd) and fcntl.
>
> Also some minor cleanup.
Looks good. Fine for mainline just after 2.6.23 opens.
-
To unsubscribe from this list: send
On Tue, Jun 26, 2007 at 07:46:15PM -0400, Trond Myklebust wrote:
> I don't object to the concept per se, but could you please give it a
> more descriptive name please? "struct vfs_intent" would be a lot more
> accurate than "nameidata2".
Agreed, but I prefer lookup_intent - intent by itself is a w
On Tue, Jun 26, 2007 at 08:11:41PM -0400, Erez Zadok wrote:
> Perhaps it is also time to put the dentry + mnt into a single struct path?
> It's a small change, but it emphasizes that the two items here, dentry+mnt,
> really define a single path to be passed around:
No. The vfsmount will go away c
On Tue, Jun 26, 2007 at 04:15:11PM -0700, [EMAIL PROTECTED] wrote:
> The create, lookup, and permission inode operations are all passed a
> full nameidata. This is unfortunate because in nfsd and the mqueue
> filesystem, we must instantiate a struct nameidata but cannot provide
> all of the same i
On Mon, Jun 25, 2007 at 05:25:00PM -0500, Steve French wrote:
> Jeff,
> Not seeing any objections to your revised approach (to not allowing
> signals for cifsd kernel thread), I just merged something similar to
> your patch to the cifs-2.6.git tree (also fixed some nearby lines that
> went past 80
43 matches
Mail list logo
