The two patches look good to me.
-
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
Nicolas Williams wrote:
On Thu, Jan 04, 2007 at 12:04:14PM +0200, Benny Halevy wrote:
I agree that the way the client implements its cache is out of the protocol
scope. But how do you interpret correct behavior in section 4.2.1?
Clients MUST use filehandle comparisons only to improve
I did cp -rl his-tree my-tree (which completed
quickly), edited the two files that needed to be patched, then did
diff -urp his-tree my-tree, which also completed quickly, as diff knows
that if two files have the same inode, they don't need to be opened.
... download one tree from kernel.org, do
Other people are of the opinion that the invention of the symbolic link
was a huge mistake.
I guess I haven't heard that one. What is the argument that we were
better off without symbolic links?
--
Bryan Henderson San Jose California
IBM Almaden Research Center
On Wed, Jan 10, 2007 at 09:38:11AM -0800, Bryan Henderson wrote:
Other people are of the opinion that the invention of the symbolic link
was a huge mistake.
I guess I haven't heard that one. What is the argument that we were
better off without symbolic links?
I suppose
Other people are of the opinion that the invention of the symbolic link
was a huge mistake.
I guess I haven't heard that one. What is the argument that we were
better off without symbolic links?
Numerous security bugs in tar (extracting a specially crafted archive with
symlinks could
In message [EMAIL PROTECTED], Jan Kara writes:
In message [EMAIL PROTECTED], Andrew Morton writes:
On Sun, 7 Jan 2007 23:12:53 -0500
Josef 'Jeff' Sipek [EMAIL PROTECTED] wrote:
+Modifying a Unionfs branch directly, while the union is mounted, is
+currently unsupported.
Erez Zadok wrote:
I didn't know about those patches, but yes, they do sound useful. I'm
curious who needed such functionality before and why. If someone can point
me to those patches, we can look into using them for Unionfs. Thanks.
I asked for it years ago, You can probably guess why :)
Jeff Layton wrote:
Resending this set of patches to the list per Al Viro's request. I've gotten
no comments so far, so I'll presume that denotes consent and just ask Andrew
to merge them if I don't hear anything after this ;-).
--[snip]-
Since Joern mentioned that he thought that
On Mon, Jan 08, 2007 at 03:47:07PM -0500, Jeff Layton wrote:
When a 32-bit program that was not compiled with large file offsets does a
stat and gets a st_ino value back that won't fit in the 32 bit field, glibc
(correctly) generates an EOVERFLOW error. We can't do anything about fs's
with
On Mon, Jan 08, 2007 at 03:47:13PM -0500, Jeff Layton wrote:
This changes the superblock creation routines that call new_inode to take
steps
to avoid later collisions with other inodes that get created. I took the
approach here of not hashing things unless is was strictly necessary, though
On Mon, Jan 08, 2007 at 03:47:17PM -0500, Jeff Layton wrote:
This converts pipefs to use the new scheme. Here we're calling iunique to get
a unique i_ino value for the new inode, and then hashing it afterward. We
call iunique with a max_reserved value of 1 to avoid collision with the root
Christoph Hellwig wrote:
return -ENOMEM;
+/* set to high value to try and avoid collisions with loop below */
+inode-i_ino = 0x;
+insert_inode_hash(inode);
This is odd. Can't we just add some constant base to the loop below?
I thought the same thing,
On Wed, Jan 10, 2007 at 05:12:15PM +0100, Jan Kara wrote:
I see :). To me it just sounds as if you want to do remount-read-only
for source filesystems, which is operation we support perfectly fine,
and after that create union mount. But I agree you cannot do quite that
since you need to have
On Wed, 10 Jan 2007 11:14:19 +0530
Suparna Bhattacharya [EMAIL PROTECTED] wrote:
On Thu, Jan 04, 2007 at 09:02:42AM -0800, Andrew Morton wrote:
On Thu, 4 Jan 2007 10:26:21 +0530
Suparna Bhattacharya [EMAIL PROTECTED] wrote:
On Wed, Jan 03, 2007 at 02:15:56PM -0800, Andrew Morton wrote:
Generic event handling mechanism.
Kevent is a generic subsytem which allows to handle event notifications.
It supports both level and edge triggered events. It is similar to
poll/epoll in some cases, but it is more scalable, it is faster and
allows to work with essentially eny kind of events.
Kevent based AIO (aio_sendfile()).
aio_sendfile() contains of two major parts: AIO state machine and page
processing code. The former is just a small subsystem, which allows to
queue callback for theirs invocation in process' context on behalf of
pool of kernel threads. It allows to queue
On Wed, Jan 10, 2007 at 06:56:40AM -0500, Jeff Garzik ([EMAIL PROTECTED]) wrote:
It was there, but Andrew dropped it somewhere about take25 :)
Probably because it was a moving target with a high rate of change,
requiring time that Andrew did not have just to keep in sync and fix
build
18 matches
Mail list logo
