On Thu, Sep 15, 2016 at 01:02:43PM -0600, Chris Murphy wrote: > On Thu, Sep 15, 2016 at 12:20 PM, Austin S. Hemmelgarn > <ahferro...@gmail.com> wrote: > > > 2. We're developing new features without making sure that check can fix > > issues in any associated metadata. Part of merging a new feature needs to > > be proving that fsck can handle fixing any issues in the metadata for that > > feature short of total data loss or complete corruption. > > > > 3. Fsck should be needed only for un-mountable filesystems. Ideally, we > > should be handling things like Windows does. Preform slightly better > > checking when reading data, and if we see an error, flag the filesystem for > > expensive repair on the next mount. > > Right, well I'm vaguely curious why ZFS, as different as it is, > basically take the position that if the hardware went so batshit that > they can't unwind it on a normal mount, then an fsck probably can't > help either... they still don't have an fsck and don't appear to want > one. > > I'm not sure if the brfsck is really all that helpful to user as much > as it is for developers to better learn about the failure vectors of > the file system. > > > > 4. Btrfs check should know itself if it can fix something or not, and that > > should be reported. I have an otherwise perfectly fine filesystem that > > throws some (apparently harmless) errors in check, and check can't repair > > them. Despite this, it gives zero indication that it can't repair them, > > zero indication that it didn't repair them, and doesn't even seem to give a > > non-zero exit status for this filesystem. > > Yeah, it's really not a user tool in my view... > > > > > > > As far as the other tools: > > - Self-repair at mount time: This isn't a repair tool, if the FS mounts, > > it's not broken, it's just a messy and the kernel is tidying things up. > > - btrfsck/btrfs check: I think I covered the issues here well. > > - Mount options: These are mostly just for expensive checks during mount, > > and most people should never need them except in very unusual circumstances. > > - btrfs rescue *: These are all fixes for very specific issues. They should > > be folded into check with special aliases, and not be separate tools. The > > first fixes an issue that's pretty much non-existent in any modern kernel, > > and the other two are for very low-level data recovery of horribly broken > > filesystems. > > - scrub: This is a very purpose specific tool which is supposed to be part > > of regular maintainence, and only works to fix things as a side effect of > > what it does. > > - balance: This is also a relatively purpose specific tool, and again only > > fixes things as a side effect of what it does.
You've forgotten btrfs-zero-log, which seems to have built itself a reputation on the internet as the tool you run to fix all btrfs ills, rather than a very finely-targeted tool that was introduced to deal with approximately one bug somewhere back in the 2.x era (IIRC). Hugo. > > Yeah I know, it's just much of this is non-obvious to users unfamiliar > with this file system. And even I'm often throwing spaghetti on a > wall. > > > -- > Chris Murphy > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Hugo Mills | It's against my programming to impersonate a deity! hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: E2AB1DE4 | C3PO, Return of the Jedi
signature.asc
Description: Digital signature
