Re: [DNG] Can this drive be saved?
On 2020-09-05 01:34, goli...@devuan.org wrote: I'll try to get the content on the drive archived over the weekend and ready for long-term storage. A bit of a followup . . . first I deleted all the files in lost+found and the drive didn't explode. Then deleted some files in the remaining directories and finally copied many GB of new data. It took quite a long time and required babysitting so a bit of a pain. Finally, I ran the SMART short test and no errors were reported. I compared the current SMART data with the one taken after the fsck and only the poweron and hours running etc. had changed. So it looks like the drive is working normally again. Keeping track of all this is taking way to much brainspace . . . Again, thanks to all. golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Lost and found: was Can this drive be saved?
On Monday 07 September 2020 at 02:39:10, Steve Litt wrote: > On Sat, 05 Sep 2020 00:43:11 -0500 > > > On 2020-09-04 22:25, Hendrik Boom wrote: > > > Delete the contents all you want, but keep the lost and found > > > directory. > Whoops. I never realized the directory was necessary, and have always > deleted it so backups wouldn't give an error message that they couldn't > back it up > So I just remade the directories I deleted ago, chmod 700, owned by > root.root. Exactly what would I expect to find in them? Plenty of pre-allocated space (which the above does not do). I suggest "man mklost+found". Antony. -- "Black holes are where God divided by zero." - Steven Wright Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] bug#228: Long description truncated from packages when using 'apt cache search'
Thanks for your patience. This issue is now resolved in the amprolla instance serving pkgmaster.devuan.org and the round-robin mirrors (deb.devuan.org) which derive from it. packages.devuan.org is deprecated and will be decommissioned very soon so its amprolla instance has not been updated. Ensure you are using deb.devuan.org in your sources.list to get long package descriptions. Mark ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Lost and found: was Can this drive be saved?
On Sun, Sep 06, 2020 at 08:39:10PM -0400, Steve Litt wrote: > On Sat, 05 Sep 2020 00:43:11 -0500 > goli...@devuan.org wrote: > > > On 2020-09-04 22:25, Hendrik Boom wrote: > > > > Delete the contents all you want, but keep the lost and found > > > directory. > > > > > > -- hendrik > > > > > > > Understood. I realize that directory is necessary and would only > > delete the contents. But a reminder is always good and might be > > useful to someone else. :) > > > > golinux > > Whoops. I never realized the directory was necessary, and have always > deleted it so backups wouldn't give an error message that they couldn't > back it up because the current destination file is root.root and can't > be backed up by slitt.slitt. > > So I just remade the directories I deleted ago, chmod 700, owned by > root.root. Exactly what would I expect to find in them? Files that have become unattached from their diretories through file-system errors. fsck puts them there instead of deleting them. But use mklost+found to create the lost+found directory, not mkdir. mklost+found makes a directory that has enough space for entries for the found files. mkdir makes an (almost) empty directory, and may not have enough space if many files are found. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Can this drive be saved?
On Sun, Sep 06, 2020 at 06:08:51PM -0400, Mason Loring Bliss wrote: > On Sat, Sep 05, 2020 at 01:41:46PM -0400, Hendrik Boom wrote: > > > Nowadays the hardware replaces individual bad blocks without bothering > > the file system. > > Where it can, yeah. That said, I've seen some of the corruption that we're > supposed to never see - the bitflips in files that people use to > demonstrate self-healing filesystems - prior to my become a ZFS zealot. > > The awfully nice thing about ZFS is that if you have a mirror or better, > each drive stores both data and a checksum of that data, so you have an > awfully good chance of finding one bit of recorded data that matches one > checksum, and if you have that, ZFS can rewrite all the bad data. Even with > a single disk, you can specify multiple copies to achieve the same thing, > although catastrophic failure of the disk is always a possibility, making a > proper mirror *and* back-ups preferable. > > As a random note, the upstream ZFS custom package instructions work out of > the box on Devuan, and they still ship sysvinit files when built that way. > > > https://openzfs.github.io/openzfs-docs/Developer%20Resources/Custom%20Packages.html > > At some point there will be other filesystems that do the same. BtrFS isn't > far behind, and hopefully some increased attention will get it the rest of > the way. Red Hat's Stratis and DragonflyBSD's Hammer2 will both have self- > healing working before long, using different approaches. There are also the md RAID machanisms, which do the duplication but not the checksumming. So if the hardware can't read a block, there's another copy on the mirror. But the lack of checksumming makes it have to rely on the hardware for error detection. It's an alternative if for some reason btrfs and xfs aren't suitable. (in my case, they weren't available in the dark ages when I first created my file systems) And I believe btrfs and zfs rely on the hardware implementing write blocks correctly. I've heard of hard disks that fail to do that properly. Those drives treat data as having been permanently recorded once they are in cache, instead of waiting until the data are actually on the hard disk surface itself. This causes trouble on unexpected power-down. I don't know if any such hard drives are still manufactured. I hope not. And are those file systems good enough for media where blocks degenerate slightly each time they are written to? The journals get a lot of write activity. The copy-on-write mechanisms are the reason those file systems have their legendary stability. But it also makes them vulnerable to errors in RAM. When stuff is read, part of it is modified, and then written back (via the journal) it has a sojourn on RAM, where there is the potential for corruption. -- hendrik > > -- > Mason Loring Bliss (( If I have not seen as far as others, it is because > ma...@blisses.org )) giants were standing on my shoulders. - Hal Abelson ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] RFC: wiki software
On Fri, Sep 04, 2020 at 12:51:01AM -0400, Mason Loring Bliss wrote: > Hi all! We're looking for opinions about wiki software. First choice at the > moment is TWiki but we want more options and more perspective to get us to > the best possible decision. Of course there's also mediawiki, which is the basis for the WIkipedia. > > Goals, not in a particular order: > > * Ideally not Python, PHP, Java unless it's otherwise perfect. > > * Supports ACLs for per-account and/or per-group editing privs. Ability to > disable edits by people not logged in. > > * Potentially supports ACL-based visibility in addition to editing privs. > > * Supports at least a minimum live editor, with mark-up being fine - no > need for WYSIWYG. > > * Flat files on the back end - ideally content can be captured to version > control, can come from version control, etc. > > * JavaScript not required for clients. > > We'll continue poking at TWiki while we gather data. Another thing you likely want is clean separation of the wiki and the wiki configuration from the user content. Having part of the wiki software or its default configuration reside on the wiki itself can cause difficulty during updates. I believe Twiki failed this demand. But that was more than a decade ago. It may be OK now. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
