I've got no reply so i resend this letter.
Roman, i'd like to finish the work and would like to ask you what is
wrong with your version of the NLS support for MacHFS. I expected it to
appear in v 2.6.12 but there's no it. I would like to proceed basing on
it if you insist.
Also i would like
On Thu, 2005-07-28 at 15:27, Bryan Henderson wrote:
> >Bryan, what would you expect the behavior to be when somebody mounts on
> >a directory what is already mounted over?
>
> Well, I've tried to beg the question. I said I don't think it's
> meaningful to mount over a directory; that one actual
>One problem with 1) [mounting into the middle of a mount stack]
>is that it breaks the assumption that an 'mount X;
>umount X' pair is a no-op.
A very good point. Since unmounts are always from the top of the stack,
for symmetry mounts should be there too.
Here's another tidbit of information
>Bryan, what would you expect the behavior to be when somebody mounts on
>a directory what is already mounted over?
Well, I've tried to beg the question. I said I don't think it's
meaningful to mount over a directory; that one actually mounts at a name.
And that Linux's peculiar "mount over '.
On Thu, 2005-07-28 at 13:44, Miklos Szeredi wrote:
> > I am not surprised when mounts on /mnt/1 do not propogate to /mnt/2/1
> > This is expected, and I am perfectly happy. Because the mount is
> > attempted on 'B' and 'B' has nobody to propogate to.
> >
> > when mount on /mnt/2/1 (i.e on C at den
> >> Does it mean to mount F immediately over D, in spite of anything that
> >> might be stacked above D right now? Or does it mean to throw F onto
> the
> >> stack which is currently sitting over D? Your analysis assumes it's
> the
> >> former, whereas what Linux does is consistent with the
> I am not surprised when mounts on /mnt/1 do not propogate to /mnt/2/1
> This is expected, and I am perfectly happy. Because the mount is
> attempted on 'B' and 'B' has nobody to propogate to.
>
> when mount on /mnt/2/1 (i.e on C at dentry 1) is attempted, I expect
> to see a new mount 'E' at th
>> Does it mean to mount F immediately over D, in spite of anything that
>> might be stacked above D right now? Or does it mean to throw F onto
the
>> stack which is currently sitting over D? Your analysis assumes it's
the
>> former, whereas what Linux does is consistent with the latter.
>
>
On Thu, 2005-07-28 at 13:35, Bryan Henderson wrote:
> It wouldn't surprise me if someone is depending on mount over ".". But
> I'd be surprised if someone is doing it to a directory that's already been
> mounted over (such that the stacking behavior is relevant). That seems
> really eccentri
On Thu, 2005-07-28 at 12:30, Miklos Szeredi wrote:
> > no. there is no asymmetry as such. the propogations are working the way
> > they are meant to. But the confusion arises because of the mount lookup
> > symantics. The reason Avantika(who is doing shared subtree testing),
> > had this exact con
> I think the issue is what does "mount F over directory D" mean?
>
> Does it mean to mount F immediately over D, in spite of anything that
> might be stacked above D right now? Or does it mean to throw F onto the
> stack which is currently sitting over D? Your analysis assumes it's the
> for
> no. there is no asymmetry as such. the propogations are working the way
> they are meant to. But the confusion arises because of the mount lookup
> symantics. The reason Avantika(who is doing shared subtree testing),
> had this exact confusion is because of the 'most-recent-mount visible'
> rule
On Thu, 2005-07-28 at 08:58, Miklos Szeredi wrote:
> > step 1: mount --bind /mnt /mnt
> > a new mount 'A' is created at /mnt
> >
> > step 2: mount --make-shared /mnt
> >mounts under 'A' are made shared. But in this case
> >there are no other mounts. So only 'A' will
I don't know enough about shared subtrees to have an opinion on what
should happen with those, but you fundamentally asked about a perceived
weirdness in existing Linux code, and I do have an opinion on that (which
is that there's no weirdness).
>On analysis it turns out the culprit is the curr
On 7/28/05, Ronald G. Minnich wrote:
>
>
> On Thu, 28 Jul 2005, Christoph Hellwig wrote:
>
> > Couldn't the two other transports be implemented ontop of this one using
> > a mount helper doing the pipe or tcp setup?
>
> that's how we did it in the version we did for 2.4. I don't see why not.
>
>On Thu, 28 Jul 2005, Andrew Morton wrote:
>> Martin Jambor <[EMAIL PROTECTED]> wrote:
>> >
>> > Do filesystems try to relocate the data from bad blocks of the
>> > device?
>
>Only Windows NTFS, not others AFAIK (most filesytems can mark them during
>mkfs, that's all).
>
>> Nope. Disks will do tha
> step 1: mount --bind /mnt /mnt
> a new mount 'A' is created at /mnt
>
> step 2: mount --make-shared /mnt
>mounts under 'A' are made shared. But in this case
>there are no other mounts. So only 'A' will be made shared.
>
>
> step 3: mkdir -p /m
On Thu, 2005-07-28 at 04:56, Miklos Szeredi wrote:
> > Here is a scenario with shared subtree. Sorry it is complex.
> >
> >
> > mount --bind /mnt /mnt
> > mount --make-shared /mnt
> > mkdir -p /mnt/p
> > mount --bind /usr /mnt/1
> > mount --bind /mnt /mnt/2
> >
> > At this stage the mount at /
> +static int v9fs_fd_recv(struct v9fs_transport *trans, void *v, int len)
> +{
> + struct v9fs_trans_fd *ts = trans ? trans->priv : NULL;
> +
> + return kernel_read(ts->in_file, ts->in_file->f_pos, v, len);
> +}
> +static int v9fs_fd_send(struct v9fs_transport *trans, void *v, int le
On Thu, Jul 28, 2005 at 08:57:23AM -0500, [EMAIL PROTECTED] wrote:
> v9fs: add file-descriptor based transport as was requested by LANL and
> Plan 9 from User Space folks.
Couldn't the two other transports be implemented ontop of this one using
a mount helper doing the pipe or tcp setup?
-
To uns
On Thu, 28 Jul 2005, Christoph Hellwig wrote:
> Couldn't the two other transports be implemented ontop of this one using
> a mount helper doing the pipe or tcp setup?
that's how we did it in the version we did for 2.4. I don't see why not.
ron
-
To unsubscribe from this list: send the line "un
v9fs: add file-descriptor based transport as was requested by LANL and
Plan 9 from User Space folks.
Signed-off-by: Eric Van Hensbergen <[EMAIL PROTECTED]>
---
commit e65b41c8081e0f7227a16d39a4bc65e2924d7680
tree 4cfd78c690d2e9852736499fe9d0a311c78beee8
parent eefccf73f82b2bdf353cd05b8e5d6142210b
> Here is a scenario with shared subtree. Sorry it is complex.
>
>
> mount --bind /mnt /mnt
> mount --make-shared /mnt
> mkdir -p /mnt/p
> mount --bind /usr /mnt/1
> mount --bind /mnt /mnt/2
>
> At this stage the mount at /mnt/2 and /mnt belong to the same pnode
> which means mounts under them
> > This is an example, where having struct pnode just complicates things.
> > If there was no struct pnode, this function would be just one line:
> > setting the shared flag.
> So your comment is mostly about getting rid of pnode and distributing
> the pnode functionality in the vfsmount structure
On Thu, 28 Jul 2005, Andrew Morton wrote:
> Martin Jambor <[EMAIL PROTECTED]> wrote:
> >
> > Do filesystems try to relocate the data from bad blocks of the
> > device?
Only Windows NTFS, not others AFAIK (most filesytems can mark them during
mkfs, that's all).
> Nope. Disks will do that interna
> yes we agreed on returning EINVAL when a directory is attempted to made
> shared/private/slave/unclonnable. But this is a different case.
>
> lets say /mnt is a mountpoint having a vfsmount (say A).
> now if you run
> mount --bind /mnt/a /tmp
> this operation succeeds currently.
>
Martin Jambor <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I have tried to find out how filesystems are supposed to handle the
> situation when an asynchronous writeout of a page fails and so had a
> look at the ext2 code. All I have found is that for example
> mpage_end_io_write sets the Error flag of
Summary of the question:
Should the topmost mount be visible, or should the most recent
mount be visible?
consider the following command sequence
(1) cd /mnt
(2) mount --bind /usr /mnt
(3) mount --bind /bin /mnt
(4) mount --bind /var .
after step 1, the pwd of the process is poin
28 matches
Mail list logo
