I have avoided using NFS because I didn't want people to have to install yet another server. But I can see that people might want to put a lot of stuff on their frontends, which would require more memory to run and to store the files. And I'm starting to see a growing list of small issues that together is swaying me towards using NFS, not the least of which is ease of development.
I'm still trying to formulate the Grand Unified Picture of how all these pieces will fit together; at the moment it is still quite nebulous. But it looks like it will involve NFS; I think running the base image of minimyth would not require NFS.
BTW, using NFS, in conjunction with translucency fs, probably means I will NOT be storing config files and other settings in the database.
Part of me says that if theres going to be any NFS, might as well make the whole thing NFS and do an NFS Root. This makes it easier to play with config settings (since theres no cramfs image to rebuild with each change) and if we're going to be going NFS anyhow... Additionally, this would let the cache files that mythtv makes when it rescales the images to different screen resolutions actually be saved. This may or may not be important.
The other part of me sees a box with a half gig of ram, very little of which seems to actually be used. If it were easy enough to have database or append-based configuration for the nfs shares i wanted mounted (like /fileserver in Hairlock's system) I wouldn't mind having a 250mb imagine in ram on the frontend. In fact, I could probably be persueded to put a 1gig stick of ram in it if necessary
This probably doesn't help out much as I'm pretty much OK with it either way. What other configuration things are there that you are considering the need to pull out of the database? I'd love to be able to set the X resolution without having the edit the XF86Config and create a new cramfs.
1) Minimyth will not be able to hold my 20G of music and 40G of movies, and although I could get the pictures of my family a friends on it, it is easiler to use the network.
2) It's quicker to boot. (and I had it set up anyway) I also have /.mythtv nfs mounted (not in my release) so Mythnews now can store information and the image cache works.
I choose nfs above samba even though it is more secure, nfs is quicker and lover cpu overhead on the server and client.
Mounting the /usr by nfs but keeping the / local (disk or memeory based) is a classic UNIX admin technique. The files in /usr generally only get read when and application gets loaded into memory, but files in /etc can be read every minute or less (e.g. named) which could put some latency in the system.
So the question is how to do it. One approach is to net-boot (or cdrom or CF, whatever) a small initrd that nfs mounts the whole enchilada and chroot's to it. The other is what Hairlocks has suggested which is to have frequently accessed files (e.g., those in /etc) in a local ramdisk and nfs mount /usr (and some other mounts for content).
The first approach seems more elegant to me, but the second seems like it would be more performant. In my professional life, I have seen a lot of very elegant projects really suck when it comes to real world performance.
I want to continue the discussion about all this. There are a number of factors to consider. I personally have not ever attempted to build any of the modules ('cept mythweb) so I am ignorant of what is required to support them, though I have a vague idea about it.
And what else needs to be considered when adding/customizing? Surely everything to be changed/added can't just go in /usr. There will likely be changes to the startup scripts (in /etc) and the minimyth "user's" home directory (which is currently / and should probably be changed).
One last comment. Once we go down this path we're not too far from having a full blown distro that could also support mythbackend. Our EPIA frontends could potentially be (diskless or not) slave backends. For me that is far in the future but something to keep in mind as we design minimyth TNG.
The new forthcoming EPIA boards put even more into that equation. Boot from and operator from compact flash. I will likely go this route and install an ide-CF adapter in my mythfrontend box. 128MB is plenty of space to have just about whatever you want. Use JFFS-2 and there are very few issues with killing your CF card due to over use of certain sectors.
I have to put Myth on the back burner (farther back) for a few more months. I'm planning a job change and move so that takes priority.
I'm pretty sure the kernel can do this all by itself without jumping through any initrd hoops. IIRC, the dhcp server tells the kernel where its nfs root filesystem lives and then the kernel mounts it automagically. Not really sure if its a patch or not but the kernel has its own dhcp client to make this work.So the question is how to do it. One approach is to net-boot (or cdrom or CF, whatever) a small initrd that nfs mounts the whole enchilada and chroot's to it. The other is what Hairlocks has suggested which is to have frequently accessed files (e.g., those in /etc) in a local ramdisk and nfs mount /usr (and some other mounts for content).
Already working on this. Once we get gar building everything correctly, I'll port it over to my slackware package making gar and have a lean and mean full blown frontend/backend epia distro. Just have to quit being so damn lazy because I think everything is already in place to make this work. Even have a link to a nice little script to make bootable install cds if someone else was interested in this. I might have to hack up the slack install program a little bit but I haven't even started working on this iso idea yet so who knows.One last comment. Once we go down this path we're not too far from having a full blown distro that could also support mythbackend. Our EPIA frontends could potentially be (diskless or not) slave backends. For me that is far in the future but something to keep in mind as we design minimyth TNG.
<vent>lmatter wrote:Just FYI (hey, this is the OT forum) the new MII epia's dont' look like they can boot off of the onboard CF adaptor, which is a real shame. I'm trying to get confirmation from one of their engineers on that.
Major bummer and stupid move on their part if that is true. Why the hell have it in there? I guess the same thing can be accomplished with some of the flash media that www.idotpc.com is carrying that plugs right into the ide connector on the motherboard.
Why is it that VIA gets soooo close some of the time, yet misses on one feature that really gets me. lvsd (lsvd?) is the other one. At least we're starting to see boards which have that on now. I mean why put everything there except the plug?
In any case, please let me know as I was planning this as one of my next purchases.
If you are going to go for an NFS solution then I would suggest going the NFS root way. I can't think of why you would want to go half way and then not have the complete system using NFS. I have been running NFSRoot pretty much since the start, I'm really happy with my system, and it boots very quickly. I also find that maintenence is much quicker and easier too.
Please lets discuss the pros and cons as you see them.