Difference between revisions of "Talk:Diskless system"

From ArchWiki
Jump to: navigation, search
m (async vs sync)
(Moderation)
Line 51: Line 51:
  
 
:: We write sections explaining why an obvious choice is actually not a good idea, so others can be informed and avoid the same mistake.  (Assuming they agree that it is actually a mistake.)  Seriously: this wiki is not here to reflect only your own opinions; it's here so that we can '''all''' share our knowledge.  It's all about collaboration and compromise, and I'm seeing very little of that from you right now.  [[User:Giddie|Giddie]] ([[User talk:Giddie|talk]]) 11:34, 11 December 2012 (UTC)
 
:: We write sections explaining why an obvious choice is actually not a good idea, so others can be informed and avoid the same mistake.  (Assuming they agree that it is actually a mistake.)  Seriously: this wiki is not here to reflect only your own opinions; it's here so that we can '''all''' share our knowledge.  It's all about collaboration and compromise, and I'm seeing very little of that from you right now.  [[User:Giddie|Giddie]] ([[User talk:Giddie|talk]]) 11:34, 11 December 2012 (UTC)
 +
 +
==Moderation==
 +
This article seems to be undergoing an edit war between [[User:Buhman]] and [[User:Giddie]], and this is bad for the wiki and its users: I remind both users that the articles of the wiki belong to everybody and can't be treated as personal notebooks. Entering more into the merits of the discussion, I also remind that it's a common policy of the ArchWiki to always explain all the possible ways to achieve a particular result, never hiding anything and always leaving the final choice to the end users; if some methods are working but discouraged for some reasons, they are to be left in the article together with those reasons of discouragement; if some methods are working only under some conditions, these conditions are to be described, possibly adding an appropriate [[:Category:Template#Article_status_templates|article status template]]. Different subsections can be created to keep the various methods separate.
 +
 +
Furthermore, I invite to always sign with the full signature in discussion pages (<nowiki>~~~~</nowiki>) and to always thoroughly justify the edits with the edit summary, avoiding expressions like "why the fsck was this even created?" or empty summaries (in particular when undoing edits), since these practices don't help in any way. Finally, please avoid expressions like "NFSv3 sucks", "Kthx", "I couldn't care less about your migration woes; it doesn't belong on the wiki, end of discussion", "That's just plain stupid", ... since this '''is''' considered ''flaming'', and flamers are not welcome here, regardless of the effective quality of their edits.
 +
 +
This section is more of a notice than a real discussion, so replies are not expected, please go on with the other discussions peacefully and constructively: once the situation has calmed down, this section can just be deleted.
 +
 +
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:39, 12 December 2012 (UTC)

Revision as of 14:39, 12 December 2012

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: https://wiki.archlinux.org/index.php?title=Network_Installation_Guide&diff=239393&oldid=239392 --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)

Note that this means that async is not about "data loss in the event of network failure". Can you please justify why you keep reverting my correction? Giddie (talk) 11:36, 11 December 2012 (UTC)

Courtesy

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)

DNSmasq

If DNSmasq is not appropriate for the job, please write a section explaining why this is the case. Since I use dnsmasq, I'd be interested to know why exactly you think it's not appropriate. What definitely is not appropriate, however, is undoing my edits, for which I've gone to pains to explain my reasoning. Giddie (talk) 10:38, 11 December 2012 (UTC)

No, we don't write sections explaining why sections don't exist. That's just plain stupid. --Buhman (talk) 10:42, 11 December 2012 (UTC)
We write sections explaining why an obvious choice is actually not a good idea, so others can be informed and avoid the same mistake. (Assuming they agree that it is actually a mistake.) Seriously: this wiki is not here to reflect only your own opinions; it's here so that we can all share our knowledge. It's all about collaboration and compromise, and I'm seeing very little of that from you right now. Giddie (talk) 11:34, 11 December 2012 (UTC)

Moderation

This article seems to be undergoing an edit war between User:Buhman and User:Giddie, and this is bad for the wiki and its users: I remind both users that the articles of the wiki belong to everybody and can't be treated as personal notebooks. Entering more into the merits of the discussion, I also remind that it's a common policy of the ArchWiki to always explain all the possible ways to achieve a particular result, never hiding anything and always leaving the final choice to the end users; if some methods are working but discouraged for some reasons, they are to be left in the article together with those reasons of discouragement; if some methods are working only under some conditions, these conditions are to be described, possibly adding an appropriate article status template. Different subsections can be created to keep the various methods separate.

Furthermore, I invite to always sign with the full signature in discussion pages (~~~~) and to always thoroughly justify the edits with the edit summary, avoiding expressions like "why the fsck was this even created?" or empty summaries (in particular when undoing edits), since these practices don't help in any way. Finally, please avoid expressions like "NFSv3 sucks", "Kthx", "I couldn't care less about your migration woes; it doesn't belong on the wiki, end of discussion", "That's just plain stupid", ... since this is considered flaming, and flamers are not welcome here, regardless of the effective quality of their edits.

This section is more of a notice than a real discussion, so replies are not expected, please go on with the other discussions peacefully and constructively: once the situation has calmed down, this section can just be deleted.

-- Kynikos (talk) 14:39, 12 December 2012 (UTC)