From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/44670 Path: main.gmane.org!not-for-mail From: Daniel Pittman Newsgroups: gmane.emacs.gnus.general Subject: Re: Gnus and resilience to datafile corruption... Date: Sun, 05 May 2002 12:04:55 +1000 Organization: Not today, thank you, Mother. Sender: owner-ding@hpc.uh.edu Message-ID: <87k7qjnyd4.fsf@enki.rimspace.net> References: <87n0vg1om6.fsf@enki.rimspace.net> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1020564395 4193 127.0.0.1 (5 May 2002 02:06:35 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 5 May 2002 02:06:35 +0000 (UTC) Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 174BQ3-00015W-00 for ; Sun, 05 May 2002 04:06:35 +0200 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 174BP3-0003Bp-00; Sat, 04 May 2002 21:05:33 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sat, 04 May 2002 21:05:47 -0500 (CDT) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id VAA27322 for ; Sat, 4 May 2002 21:05:35 -0500 (CDT) Original-Received: (qmail 3599 invoked by alias); 5 May 2002 02:05:15 -0000 Original-Received: (qmail 3594 invoked from network); 5 May 2002 02:05:15 -0000 Original-Received: from melancholia.rimspace.net (HELO melancholia.danann.net) (210.23.138.19) by gnus.org with SMTP; 5 May 2002 02:05:15 -0000 Original-Received: from localhost (melancholia.rimspace.net [210.23.138.19]) by melancholia.danann.net (Postfix) with ESMTP id 6B6842A823 for ; Sun, 5 May 2002 12:04:58 +1000 (EST) Original-Received: by localhost (Postfix, from userid 1000) id A218510F178; Sun, 5 May 2002 12:04:55 +1000 (EST) Original-To: ding@gnus.org In-Reply-To: (prj@po.cwru.edu's message of "Sat, 04 May 2002 19:58:15 -0400") Original-Lines: 64 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.5 (bamboo, i686-pc-linux) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:44670 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:44670 On Sat, 04 May 2002, Paul Jarc wrote: > Daniel Pittman wrote: >> It would seem reasonable to create a .properties file, similar to the >> .marks, that stored individual group properties in the nnml groups. > > This could be done, sort of, but not very well without an enhancement > to the backend interface. Backends can update Gnus's copy of the > group parameters, but backends aren't ever notified when the user > changes parameters a la -request-set-mark for marks, so they can't > tell whether their copy or Gnus's copy is more up to date. Hrm. This should be practical to implement, yes? It would require extending the interface to support a nnfoo `-request-set-properties' method, then call that on the backend when it's implemented. That should be backward compatible, yes? It also sounds practical to do, so I will look at writing it up. >> * nntp group marks and properties >> >> These are only stored in the .newsrc.eld file, resulting in my losing >> all the information about them. WIBNI they were stored in the nnml >> redundant and split style somewhere? > > If you want redundancy, keep backups. I do, but not quite so up to date as the application specific ones that NNML maintains. :) > Duplicating information storage is pointless when Gnus has no way of > knowing that one form of storage is more reliable than another. It's > just one more thing that can break. As my recent experience shows, there is some value in this duplication. Gnus may not know the difference in reliability but /I/ do. I lost vastly less information in NNML than in other backends as a result of it's more decentralized organization. In the end I wouldn't care if .newsrc.eld didn't exist -- confining the data loss from filesystem corruption to individual groups rather than *all* groups would be better as far as I am concerned. The NNML technique for storing information has also proved more reliable in the face of minor disk corruption, from bad blocks, as well as rapid corruption from broken kernels. > Note that you can specify all your group properties in the > gnus-parameters variable, if your .gnus is more reliable than your > .newsrc.eld. It's not, because it's a different single file. It would have lived through the filesystem corruption with no data loss but the bad block would have killed it if it happened to be in that file. Central storage is, by it's nature, less reliable than distributed storage. Daniel -- If you feel you have both feet planted on level ground, then the university has failed you. -- Robert F. Goheen