hello,
i have some questions on re-exporting nfs mounts.
is there a logical reason why re-exporting is not done
(apart from security considerations)?
i'm considering modifying the knfsd source to remove
the FS_REQUIRES_DEV check, or give an option to
re-export.
is there a logical fallacy to re-exporting? i'm not
concerned about security as this will be between
trusted machines/users.
apart from the FS_REQUIRES_DEV check, i can think of
the following possible changes i'd need to make:
1. i_generation number handling
2. providing a stable device number from, say, the
mountpoint name.
is there anything else i'd need to take care of? what
about inode handling?
thank you for any discussion and answers that come out
of this.
-gk
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
is there an irc channel where nfs/nfsd kernel
developers hangout?
-goutham
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
I tried the re-export described below by removing the
FS_REQUIRES_DEV check in nfsd, and providing
fictitious device numbers from a hash of the
mountpoint name, generating inode numbers from the
fileid in nfs client, etc. (parts of which are
already done in some fashion by VFS)
(I'm using the 2.4.20-6 kernel that comes with RH9.
nfs-utils 1.0.6.)
It works for small tests - creating and deleting
directories and files, writing small files. But when I
try to run anything more serious such as the
Connectathon test suite, it causes a Kernel OOPS such
as:
NFS: commit (9/1176589 4096@0)
<1>Unable to handle kernel NULL pointer dereference at
virtual address 00000009
printing eip:c015359b
*pde = 00000000
Oops: 0000
nfsd nfs lockd sunrpc parport_pc lp parport autofs
8139too mii ipt_REJECT iptable_filter ip_tables sg
sr_mod ide-scsi scsi_mod ide-cd cdrom ohci1394
ieee1394
EIP is at fput [kernel] 0x1b (2.4.20-6smp)
Does anyone have an idea why this happens? Any idea
where the problem could be? I'm trying to understand
why this should be so complicated.
goutham
--- gKurra <[email protected]> wrote:
>
> hello,
>
> i have some questions on re-exporting nfs mounts.
>
> is there a logical reason why re-exporting is not
> done
> (apart from security considerations)?
>
> i'm considering modifying the knfsd source to remove
> the FS_REQUIRES_DEV check, or give an option to
> re-export.
>
> is there a logical fallacy to re-exporting? i'm not
> concerned about security as this will be between
> trusted machines/users.
>
> apart from the FS_REQUIRES_DEV check, i can think of
> the following possible changes i'd need to make:
>
> 1. i_generation number handling
> 2. providing a stable device number from, say, the
> mountpoint name.
>
> is there anything else i'd need to take care of?
> what
> about inode handling?
>
> thank you for any discussion and answers that come
> out
> of this.
>
> -gk
>
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product
> search
> http://shopping.yahoo.com
>
>
>
-------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> NFS maillist - [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfs
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs