the file from IMA?
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
IMA?
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
"J. Bruce Fields":
> On Wed, Feb 19, 2014 at 12:27:53AM +0900, J. R. Okajima wrote:
> >
> > There is a regression in
> > 208d0ac 2014-01-07 nfsd4: break only delegations when appropriate
> > which deletes an nfserrno() call in nfsd_setattr() (by acci
J. Bruce Fields:
On Wed, Feb 19, 2014 at 12:27:53AM +0900, J. R. Okajima wrote:
There is a regression in
208d0ac 2014-01-07 nfsd4: break only delegations when appropriate
which deletes an nfserrno() call in nfsd_setattr() (by accident,
probably), and NFSD becomes ignoring an error
an inode for every whiteout? I'd suggest making a
hardlink. For some filesystems which don't support hardlinks, we have to
consume an inode per whiteout. But when the fs supports hardlinks, we
can re-use the inode and consume a few inodes only.
J. R. Okajima
--
To unsubscribe from this list: send
for every whiteout? I'd suggest making a
hardlink. For some filesystems which don't support hardlinks, we have to
consume an inode per whiteout. But when the fs supports hardlinks, we
can re-use the inode and consume a few inodes only.
J. R. Okajima
--
To unsubscribe from this list: send the line
There is a regression in
208d0ac 2014-01-07 nfsd4: break only delegations when appropriate
which deletes an nfserrno() call in nfsd_setattr() (by accident,
probably), and NFSD becomes ignoring an error from VFS.
Here is a patch to fix it.
J. R. Okajima
diff --git a/fs/nfsd/vfs.c b/fs
There is a regression in
208d0ac 2014-01-07 nfsd4: break only delegations when appropriate
which deletes an nfserrno() call in nfsd_setattr() (by accident,
probably), and NFSD becomes ignoring an error from VFS.
Here is a patch to fix it.
J. R. Okajima
diff --git a/fs/nfsd/vfs.c b/fs
e time,
then does squashfs simply return ENOMEM because the memory shrinker
cannot run on any core?
If it is true, we may need a rule "no new resources for decompressing"
since users may prefer the "slow but successful decompression" than
getting ENOMEM.
If this mail is totaly poi
core?
If it is true, we may need a rule no new resources for decompressing
since users may prefer the slow but successful decompression than
getting ENOMEM.
If this mail is totaly pointless, please ignore.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
actual rename on a branch and then handles other actions (make it opaque,
update the attributes, etc). If an error happens in these actions, aufs
simply renames the whiteouted name back and returns an error. If all are
succeeded, aufs registers a function to remove the whiteouted unique
tempor
and returns an error. If all are
succeeded, aufs registers a function to remove the whiteouted unique
temporary name completely and asynchronously to the system global
workqueue.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
h one more prefix, the name loses the role of
whiteout. Aufs simply ignores such doubly whiteouted name.
The demerit is that aufs has to limit the length of the name.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord.
_pos);
mutex_unlock(>i_mutex);
:::
sb_end_write(inode->i_sb);
Process C would block *BEFORE* i_mutex by sb_start_write()? No?
Honestly speaking I didn't pay attention about the freeze feature since
I don't use it. I am making aufs to support it now. But I do
ning feature is not implemented as a fs, the solution will not
be so easy. I am afraid UnionMount will need to introduce a new counter
(or a new flag) to indicate the task entered the union, and adjust the
lock class or decide to call lockdep_off() for sb_writers. I don't think
it is a good idea.
J
is not implemented as a fs, the solution will not
be so easy. I am afraid UnionMount will need to introduce a new counter
(or a new flag) to indicate the task entered the union, and adjust the
lock class or decide to call lockdep_off() for sb_writers. I don't think
it is a good idea.
J. R. Okajima
-i_mutex);
:::
sb_end_write(inode-i_sb);
Process C would block *BEFORE* i_mutex by sb_start_write()? No?
Honestly speaking I didn't pay attention about the freeze feature since
I don't use it. I am making aufs to support it now. But I don't know how
to test it...
J. R. Okajima
whiteouted name.
The demerit is that aufs has to limit the length of the name.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
ked file. While
vfs_unlink() rejects such case, it may not matter for the underlying fs.
Need to verify FS including jounals.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
that the target name is still available for copyup
- make the completed file visible by -link()
It is ineteresting to -link() with the unlinked file. While
vfs_unlink() rejects such case, it may not matter for the underlying fs.
Need to verify FS including jounals.
J. R. Okajima
--
To unsubscribe
orting. When the FS is a network filesystem,
the new d_type has to be available on both of server and client. Of
course, the server may be other than linux. Even if FS is local, users
may setup dual-boot. And the other OS has to recognize the new d_type
value.
I still doubt it is a good approach.
J. R. Okaji
would be
harder to be merged.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to be merged.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
of server and client. Of
course, the server may be other than linux. Even if FS is local, users
may setup dual-boot. And the other OS has to recognize the new d_type
value.
I still doubt it is a good approach.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
turn from
btrfs. For example, repeat "ln fileA $very_lng_filename", then btrfs
returns EMLINK so soon.
And aufs refers the common set of inode attribute. I mean attrs declared
in VFS. Also I know some filesystems don't maintain attrs on each
operation. For such fs, aufs calls vfs_get
. For example, repeat ln fileA $very_lng_filename, then btrfs
returns EMLINK so soon.
And aufs refers the common set of inode attribute. I mean attrs declared
in VFS. Also I know some filesystems don't maintain attrs on each
operation. For such fs, aufs calls vfs_getattr() internally.
J. R. Okajima
esented
> > +by its filename. UnionMount takes an approach of a file mode, but I am
> > +afraid several utilities (find(1) or something) will have to support it.
>
> Why the devil should find(1) even see them?
It is the case when find(1) for the layer-fs/branch-fs directly.
J.
ersion is aufs3 (for linux-3.x series), there is no essential
changes about whiteout since aufs2.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/m
little.
Filesystems may have a limit for the consumed size by xattr. If xattr
reaches the limit, then several operation in overlayfs will be unusable.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger
size by xattr. If xattr
reaches the limit, then several operation in overlayfs will be unusable.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
-3.x series), there is no essential
changes about whiteout since aufs2.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
an approach of a file mode, but I am
+afraid several utilities (find(1) or something) will have to support it.
Why the devil should find(1) even see them?
It is the case when find(1) for the layer-fs/branch-fs directly.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux
to mainline, but if the development
of UnionMount is really stopped, then I'd ask people to consider merging
aufs as well as overlayfs.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
, then I'd ask people to consider merging
aufs as well as overlayfs.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
s. One approach is
implemented in aufs. I guess you will try another one. That is what I am
interesed.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kerne
) to
GIT on SourceForge due to the request from Ubuntu people.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to the request from Ubuntu people.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
is
implemented in aufs. I guess you will try another one. That is what I am
interesed.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
thread in detail.
[RFC 0/5] pathconf(3) with _PC_LINK_MAX
<http://marc.info/?l=linux-kernel=126008634810706=2>
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
in detail.
[RFC 0/5] pathconf(3) with _PC_LINK_MAX
http://marc.info/?l=linux-kernelm=126008634810706w=2
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
nMount is really stopped, then I'd ask people
to consider merging aufs as well as overlayfs.
but I am not sure whether LKML people are still waiting for UnionMount
and rejecting aufs.
J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
to consider merging aufs as well as overlayfs.
but I am not sure whether LKML people are still waiting for UnionMount
and rejecting aufs.
J. R. Okajima
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
101 - 142 of 142 matches
Mail list logo
