Talk:Diskless system

From ArchWiki
Revision as of 15:46, 8 December 2012 by Giddie (Talk | contribs) (Separate /var)

Jump to: navigation, search

Diskless_Network_Boot_NBD_Root merge and rewrite

There was a bunch of extraneous stuff that was clogging up the old articles, and most information was duplicated between the two. This is the result of the cleanup effort. That gPXE stuff, for example, deserves its own article in my opinion. Yet-another refactoring/merging of the related PXE article is also planned--the two should be sub-articles of a larger "PXE" article that describes "PXE" in general, with sub-articles describing booting installation media or an arch installation (minimizing duplicated information yet even more). --Buhman (talk) 14:31, 9 October 2012 (UTC)

NFSv3 sucks

Stop making edits that indicate otherwise. Kthx --Buhman (talk) 04:41, 8 December 2012 (UTC)

I run a diskless cluster at work and would love to use NFSv4. However, to the best of my knowledge it's not currently possible. Had you followed these instructions? There was a mix of v4 and v3 (loading nfsv3 in initramfs but trying to mount v4), and the "v4" option passed on the kernel line was actually rejected by initramfs. I contacted the author of mkinitcpio a few months back, and he confirmed that NFSv4 is not yet supported. I tried it again briefly yesterday with no joy, and the mkinitcpio-nfs-utils git repo shows no obvious work to support v4. Do you have any new information? NFSv3 is pretty decent; I don't think it's sensible to say it sucks just because it's not the newest version.. Giddie (talk) 9:40 UTC

It's cake: --Buhman (talk) 11:03, 8 December 2012 (UTC)
Have you contacted the author about implementing this officially and to check there are no potential issues with this approach? It seems too simple. Giddie (talk)
You mean too simple to ignore ;P --Buhman (talk) 11:25, 8 December 2012 (UTC)
I mean too simple for him to have not thought of it when it was discussed some time ago. I'm worried you've overlooked race conditions or locking issues, or idmapping. Corner cases that could turn ugly. I really don't know your credentials, so I can't trust this. In the mean time, there are people who want to use the supported setup, which is NFSv3 right now. Giddie (talk)
"race conditions"? "locking issues"? You seem to be implying that the NFSv4 protocol and/or implementation itself is flawed, or that there is some magical different between a "root filesystem" mount and any other mount that makes it a special case. I don't know if you've looked at the sources for nfsmount; but it's full of nasty--I trust the upstream mount.nfs4 far more. --Buhman (talk) 11:40, 8 December 2012 (UTC)
Do you understand why it's full of nasty? Early boot is tricky. I'd like some confirmation from the maintainer that this approach is actually sensible. Maybe he simply overlooked it, but it's equally possible that you don't know what you're talking about and this is asking for trouble. Either way, why is this hack on the wiki and not being discussed on the mailing lists? Again: the wiki should address supported setups first of all, and preferably not say they "suck". Giddie (talk)

Separate /var

Buhman, can you explain to me why you think a separate /var is not necessary? Bad things happen when clients share /var: they'll clobber each-other's logs, locks, spools, and caches. Can you please reassure me that you've tested what you're writing in a serious context? Having you unilaterally changing all this content worries me greatly. Giddie (talk)

Hehe, you didn't explain this earlier. I was mainly offended by your initscript hack (we want to expunge that from the wiki, not create more of it), which I ended up removing with the rest of the sysv-stuff in my recent edit-flurry. Locks? No, that's already tmpfs. Cache isn't really important; that can be "clobbered" all day and nothing will care. I would argue that a shared-spool, would make, e.g: "local" mail-delivery uniform across all hosts, and that this behavior is desirable.
/var/log would only be of interest if you actually cared about the logs of your diskless clients; I don't. But having explained yourself, I see how that might be worthwhile (but not "important"). The real way to do that, however, would be to either add that mount /etc/fstab like everything else (tmpfs would be appropriate there) or make a mount unit. --Buhman (talk) 11:25, 8 December 2012 (UTC)
I'm half way through migrating our cluster to systemd. What's with the desperate removal of all things initscript? Let things settle for a bit! A systemd unit will follow when I've written it. In the meantime, it kind of feels like you're taking over here and expecting that your opinion is the only correct one. I researched my cluster carefully, and I am quite confident that a shared /var is a bad idea. I still don't know if you run one of these clusters. If so, I might take your opinion more seriously. Giddie (talk)
I couldn't care less about your migration woes; it doesn't belong on the wiki, end of discussion. --Buhman (talk) 11:42, 8 December 2012 (UTC)
Hang on, you talk like you own the place. The wiki is a place for everyone to pool knowledge, not a platform to push your own opinion. Giddie (talk)
I wonder if your usecase is more temporary clients, since you talk about not caring about logs and other stuff in /var. Mine is permanent nodes, which I cluster with SLURM, also running BOINC at times. That simply doesn't work without separate /vars, because the nodes can't process anything independantly if /var is shared. Mine is not an edge-case setup. Plenty of people need Beowulf clusters. Again: what are your credentials/experience in this area? Giddie (talk)

async vs sync

The issue here is a server crash after the RPC request was returned but before the server synced to disk. Network failure is easily handled by TCP and the NFS protocol. Also, sync is the default. Let's avoid needlessly overriding defaults. Giddie (talk)


Please avoid words like "nonsense" and "probably not necessary" without foundation in reference to other people's material. They don't paint a good picture of you or the reliability of your edits. Giddie (talk)