Re: fsck updating but not fixing filesystem
> I have a reasonably large ffs filesystem (7.4GB, 35,459,874 files) I gues you mean 7.4TB? I remember (shudder) something similar, where the file server would panic (bad dir), fsck would fix some dirs (missing . or ..), the file server would panic ... rinse and repeat. Slightly short of me performing dump-newfs-restore, the problem disappeared. I never found out what was wrong. I think the general consensus is that ffs can be inconsistent it ways fsck is unable to detect.
Re: fsck updating but not fixing filesystem
On Sun, 23 Aug 2020 at 20:50, David Holland wrote: > > On Sun, Aug 23, 2020 at 08:14:31PM +0100, David Brownlee wrote: > > > > This time I've run fsck -f repeatedly and each time it marks the > > filesystem as clean, but the next run finds another issue. > > > > This is netbsd-9 amd64 stable from nyftp, DELL, PERC H710P controller, > > running RAID1. > > Are you sure the raid is clean? If it's not you can get bizarre > behavior like this depending on which side of it any given read is > serviced from. (That is: any given fsck run will see some of one > version and some of the other and make some changes, which may or may > not be consistent with what it sees the next time, and it all might > converge or might not...) No problems are indicated by envstat for mfii, or in the BIOS setup interface (Careful phrasing there). However, I have a spare 8TB disk I can attach to the onboard ahcisata, dd the filesystem across and re-run the fsck to confirm. (I may be a little while in following up with that result :) On Sun, 23 Aug 2020 at 21:26, Michael Cheponis wrote: >[...] > Then I was wondering: given today's disks are mostly lying to the software > about how its (internally) configured --- is there a 'better' FFS > (FFSv3 ?) that would better map to today's disks? Might there be a better > FFSvN for SSDs vs big HDs? Or just wait till ZFS is up to snuff? I would seriously consider ZFS - I have a couple of other boxes running ZFS, but this particular one panics if any zpool is mounted in multiuser (kern/55602) David
Re: fsck updating but not fixing filesystem
> I think the general consensus is that ffs can be inconsistent it ways > fsck is unable to detect. ...much less fix. Yes. When I was doing the program that eventually got massaged into resize_ffs, during development I had some filesystems that were definitely corrupted but that fsck was happy with. (I rather wish I'd saved some of them as test cases, but I didn't.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: fsck updating but not fixing filesystem
On Mon, 24 Aug 2020 at 11:46, Mouse wrote: > > > I think the general consensus is that ffs can be inconsistent it ways > > fsck is unable to detect. > > ...much less fix. Yes. When I was doing the program that eventually > got massaged into resize_ffs, during development I had some filesystems > that were definitely corrupted but that fsck was happy with. (I rather > wish I'd saved some of them as test cases, but I didn't.) Sounds like there is an in interesting fuzzing project in there for someone - make a filesystem mage and the repeatedly damage it, then see if fsck can fix it, then if you get a rump panic when moving everything around, and then re-run fsck to see if it indicates any new issues :) (So far 3.5TB of my original RAID1 filesystem transferred to a plain disk, so should be able to run some A/B fsck tests later today to establish if the raid controller is the issue in this case) David David
Re: "wireguard" implementation improperly merged and needs revert
Hi Jason, > We still need to protect the unique identity and reputation of > WireGuard (our "brand"). This ensures that when people see the > WireGuard name or logo, they know it is something we, the > WireGuard developers, have worked on." Personally, I would be in favour of entirely rebranding the NetBSD implementation to avoid this, because it's only introducing ourselves to potential legal problems. It's important that the NetBSD tree remains as free as possible, and that nobody introduce themselves to potential legal pain by modifying any part of it. We have also had a similar discussion with Mozilla's lawyers and simply opted to unbrand all of their software which we distribute. If only certain people can develop implementations of this protocol, this is not an open protocol.
Re: fsck updating but not fixing filesystem
Another data point: I can't remember ever when NTFS didn't come up clean after a crash, except of course when the disk itself was bad. "NTFS (NT File System) is a proprietary journaling file system developed by Microsoft. Starting with Windows NT 3.1, it is the default file system of the Windows NT family." On Mon, Aug 24, 2020 at 7:41 AM David Brownlee wrote: > On Mon, 24 Aug 2020 at 11:46, Mouse wrote: > > > > > I think the general consensus is that ffs can be inconsistent it ways > > > fsck is unable to detect. > > > > ...much less fix. Yes. When I was doing the program that eventually > > got massaged into resize_ffs, during development I had some filesystems > > that were definitely corrupted but that fsck was happy with. (I rather > > wish I'd saved some of them as test cases, but I didn't.) > > Sounds like there is an in interesting fuzzing project in there for > someone - make a filesystem mage and the repeatedly damage it, then > see if fsck can fix it, then if you get a rump panic when moving > everything around, and then re-run fsck to see if it indicates any new > issues :) > > (So far 3.5TB of my original RAID1 filesystem transferred to a plain > disk, so should be able to run some A/B fsck tests later today to > establish if the raid controller is the issue in this case) > > David > > > David >
Re: "wireguard" implementation improperly merged and needs revert
Hi Nia, On Mon, Aug 24, 2020 at 5:57 PM nia wrote: > > Hi Jason, > > > We still need to protect the unique identity and reputation of > > WireGuard (our "brand"). This ensures that when people see the > > WireGuard name or logo, they know it is something we, the > > WireGuard developers, have worked on." > > Personally, I would be in favour of entirely rebranding the NetBSD > implementation to avoid this, because it's only introducing ourselves > to potential legal problems. > > It's important that the NetBSD tree remains as free as possible, and > that nobody introduce themselves to potential legal pain by modifying > any part of it. > > We have also had a similar discussion with Mozilla's lawyers and > simply opted to unbrand all of their software which we distribute. > > If only certain people can develop implementations of this protocol, > this is not an open protocol. Please read the reply I just wrote to Maya on tech-net: https://mail-index.netbsd.org/tech-net/2020/08/24/msg007855.html where I basically covered this already. I think you've been misled by others' comments into somehow thinking this is related to trademark stuff, when it isn't at all. And this isn't a situation with "Mozilla's lawyers" or something either; there's no comparison, simply because a "trademark" is simply not part of this discussion here -- i.e. were the question to come up when we're all ready to go here about NetBSD using the name WireGuard to describe its implementation, the answer would be an "of course" and if the question were then, "can you put that in writing?" the answer would be, "yea, sure, why not." This also doesn't have anything to do with "who implements the protocol". Rather, the issue here is that NetBSD doesn't actually implement WireGuard and its protocol. There's a lot more to WireGuard than just crafting some packets that sometimes have the right crypto. I'm afraid that Ozaki-san's code has been picked up with too much haste and not enough study, and we're going to get into an ugly situation if we don't put the breaks on now, before expectations run too high, and reevaluate/restudy. And just to put this discussion back into perspective, I *like* the NetBSD project and I *want* to have everything work as smoothly as possible, and I'm volunteering my *own development time* into helping to make that happen. All I'm asking is that this trajectory here is slowed so that we can do it right. Because I care about getting it right. Jason
