No one guarantees you sane result of tar or cp -a while changing the tree.
I don't see how is_samefile() could make it worse.
There are several cases where changing the tree doesn't affect the
correctness of the tar or cp -a result. In some of these cases using
samefile() instead of
On Fri 2007-01-05 16:15:41, Miklos Szeredi wrote:
And does it matter? If you rename a file, tar might skip it no matter of
hardlink detection (if readdir races with rename, you can read none of
the
names of file, one or both --- all these are possible).
If you have dir1/a
Hi!
No one guarantees you sane result of tar or cp -a while changing the
tree.
I don't see how is_samefile() could make it worse.
There are several cases where changing the tree doesn't affect the
correctness of the tar or cp -a result. In some of these cases using
There's really no point trying to push for such an inferior interface
when the problems which samefile is trying to address are purely
theoretical.
Oh yes, there is. st_ino is powerful, *but impossible to implement*
on many filesystems.
You mean POSIX compliance is impossible? So what?
You mean POSIX compliance is impossible? So what? It is possible to
implement an approximation that is _at least_ as good as samefile().
One really dumb way is to set st_ino to the 'struct inode' pointer for
example. That will sure as hell fit into 64bits and will give a
unique (alas
Hello!
You mean POSIX compliance is impossible? So what? It is possible to
implement an approximation that is _at least_ as good as samefile().
One really dumb way is to set st_ino to the 'struct inode' pointer for
example. That will sure as hell fit into 64bits and will give a
unique
On Mon, 8 Jan 2007, Andrew Morton wrote:
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.
Does this mean that if I have /a/b/ and /c/d/ unionised under /mnt/union, I
am
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 hashing the inodes might
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
that does mean that filesystem authors need to be careful to avoid
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
inode. Since the inode is now hashed, we need to take care that we
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.
Does this mean that if I have /a/b/ and /c/d/ unionised under
On Mon, 8 Jan 2007 14:43:39 -0500 (EST)
Shaya Potter [EMAIL PROTECTED] wrote:
On Mon, 8 Jan 2007, Andrew Morton wrote:
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
On Sun, 7 Jan 2007 23:13:11 -0500
Josef 'Jeff' Sipek [EMAIL PROTECTED] wrote:
From: Josef Jeff Sipek [EMAIL PROTECTED]
This patch contains many macros and inline functions used thoughout Unionfs.
..
+#define ibstart(ino) (UNIONFS_I(ino)-bstart)
+#define ibend(ino) (UNIONFS_I(ino)-bend)
On Sun, 7 Jan 2007 23:12:56 -0500
Josef 'Jeff' Sipek [EMAIL PROTECTED] wrote:
From: Josef Jeff Sipek [EMAIL PROTECTED]
This patch contains helper functions used through the rest of the code which
pertains to files.
Signed-off-by: Josef Jeff Sipek [EMAIL PROTECTED]
Signed-off-by: David
On Mon, 2007-01-08 at 21:24 +0100, Jan Engelhardt wrote:
On Jan 8 2007 14:43, Shaya Potter wrote:
On Mon, 8 Jan 2007, Andrew Morton wrote:
On Sun, 7 Jan 2007 23:12:53 -0500
Josef 'Jeff' Sipek [EMAIL PROTECTED] wrote:
+Modifying a Unionfs branch directly, while the union is
On Sun, 7 Jan 2007 23:13:10 -0500
Josef 'Jeff' Sipek [EMAIL PROTECTED] wrote:
+ if (tmp_page)
+ free_page((unsigned long) tmp_page);
free_page(0) is legal.
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
On Mon, 2007-01-08 at 13:19 -0800, Andrew Morton wrote:
On Mon, 8 Jan 2007 14:43:39 -0500 (EST) Shaya Potter [EMAIL PROTECTED]
wrote:
It's the same thing as modifying a block
device while a file system is using it. Now, when unionfs gets confused,
it shouldn't oops, but would one
On Sun, 7 Jan 2007 23:12:58 -0500
Josef 'Jeff' Sipek [EMAIL PROTECTED] wrote:
From: Josef Jeff Sipek [EMAIL PROTECTED]
This patch contains the dentry operations for Unionfs.
+/* declarations added for sparse */
+extern int unionfs_d_revalidate_wrap(struct dentry *dentry,
+
On Jan 8 2007 15:51, Erez Zadok wrote:
BTW, this is a problem with all stackable file systems, including
ecryptfs. To be fair, our Unionfs users have come up against this
problem, usually for the first time they use Unionfs :-). Then we
tell not to do that, but that if they have to, to run
On Mon, 08 Jan 2007 16:30:48 -0500
Shaya Potter [EMAIL PROTECTED] wrote:
On Mon, 2007-01-08 at 13:19 -0800, Andrew Morton wrote:
On Mon, 8 Jan 2007 14:43:39 -0500 (EST) Shaya Potter [EMAIL PROTECTED]
wrote:
It's the same thing as modifying a block
device while a file system is using
Is there vendor interest in unionfs?
MANY live cds seem to use it.
-
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
Currently, XFS uses BH_PrivateStart for flagging unwritten
extent state in a bufferhead. Recently, i found the long standing
mmap/unwritten extent conversion bug, and it was to do with
partial page invalidation not clearing the unwritten flag from
bufferheads attached to the page but beyond EOF.
this doesn't look like a full first class flag to me yet. Don't
we need to check for buffer_unwritten in the places we're checking
for buffer_delay so we can stop setting buffer_delay for unwritten
buffers?
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a
On Mon, Jan 08, 2007 at 03:51:31PM -0500, Erez Zadok wrote:
BTW, this is a problem with all stackable file systems, including
ecryptfs. To be fair, our Unionfs users have come up against this
problem, usually for the first time they use Unionfs :-).
I suspect that the only reason why this has
On Mon, Jan 08, 2007 at 02:02:24PM -0800, Andrew Morton wrote:
On Mon, 08 Jan 2007 16:30:48 -0500
Shaya Potter [EMAIL PROTECTED] wrote:
On Mon, 2007-01-08 at 13:19 -0800, Andrew Morton wrote:
On Mon, 8 Jan 2007 14:43:39 -0500 (EST) Shaya Potter [EMAIL PROTECTED]
wrote:
It's the
On Jan 8 2007 14:02, Andrew Morton wrote:
Shaya Potter [EMAIL PROTECTED] wrote:
the difference is bind mounts are a vfs construct, while unionfs is a
file system.
Well yes. So the top-level question is is this the correct way of doing
unionisation?.
I suspect not, in which case unionfs is
On Mon, Jan 08, 2007 at 05:00:18PM -0600, Michael Halcrow wrote:
On Mon, Jan 08, 2007 at 03:51:31PM -0500, Erez Zadok wrote:
BTW, this is a problem with all stackable file systems, including
ecryptfs. To be fair, our Unionfs users have come up against this
problem, usually for the first
On Mon, Jan 08, 2007 at 10:54:02PM +, Christoph Hellwig wrote:
this doesn't look like a full first class flag to me yet. Don't
we need to check for buffer_unwritten in the places we're checking
for buffer_delay so we can stop setting buffer_delay for unwritten
buffers?
That would be
In message [EMAIL PROTECTED], Andrew Morton writes:
On Mon, 08 Jan 2007 16:30:48 -0500
Shaya Potter [EMAIL PROTECTED] wrote:
Well yes. So the top-level question is is this the correct way of doing
unionisation?.
I suspect not, in which case unionfs is at best a stopgap until someone
On Mon, 8 Jan 2007 15:51:31 -0500, Erez Zadok wrote:
Now, we've discussed a number of possible solutions. Thanks to suggestions
we got at OLS, we discussed a way to hide the lower namespace, or make it
readonly, using existing kernel facilities. But my understanding is that
even it'd work,
On Tue, Jan 09, 2007 at 01:19:48AM +0100, Giuseppe Bilotta wrote:
As a simple user without much knowledge of kernel internals, much less
so filesystems, couldn't something based on the same principle of
lsof+fam be used to handle these situations?
Using inotify has been suggested before. That
On Jan 8 2007 19:33, Josef Sipek wrote:
On Tue, Jan 09, 2007 at 01:19:48AM +0100, Giuseppe Bilotta wrote:
As a simple user without much knowledge of kernel internals, much less
so filesystems, couldn't something based on the same principle of
lsof+fam be used to handle these situations?
Using
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
33 matches
Mail list logo
