On Mon, May 24, 2010 at 03:11:23PM -0700, Elliott Mitchell wrote:
> Any update?
I continue to think this is hopelessly complex and not worth the
effort.
If you hate precautionary checks so much, then turn them off. The
tools for doing this are within your hands. Or do them using a LVM
snapshot.
> Should /I/ create a second bug report and attach it to util-linux? (or
> are you going to do the honors?) Thought I saw the current BTS can have a
> report shared amoung multiple packages...
Only if you are willing to do the heavy lifting to either (a) write
the patch, or (b) convince the util-linux folks that they should try
to implement it. I will them that IMHO it's not worth their effort,
but if they have nothing better to do, they're welcome to do whatever
they want with their time.
(Something people don't seem to understand is free software means *you*
can do whatever you want with the code. It does not mean that the
maintainer has to take any patch that any crackpot sends them, or that
a maintainer has to implement every crackpot idea that someone sends
to them.)
Still, if *you* really need this, don't let me stop you, or don't let
me stop you from paying some programmer you hire to implement it.
When I see code I can comment on whether it's something I am willing
to maintain for the long haul. (And similarly, the util-linux-ng
folks can decide whether they are willing to maintain it for the long
haul.)
> Pass 2: (delayed task, queued by init scripts, but post-boot)
> Scan all read-only filesystems, allowing precautionary checks in
> background.
In general it's not a great idea to modify a mounted filesystem, even
one mounted read-only, while it is being used. Most of the time it
will be mostly safe, but there is always the chance that a changing
the file system out from under it will cause random undefined
behaviour, including potential kernel BUG_ON's. We do it for the root
file system because we don't really have the choice, and during the
boot sequence the init scripts aren't really actively accessing the
filesystem while the fsck is running.
> Two concerns. First, what is the significance of return codes >=4 from a
> low-level fsck?
RTFM. It's in the 3rd paragraph of the fsck man page....
> If these merely mean filesystem was altered in a way that
> invalidates kernel structures, isn't this non-problematic in the case of
> a filesystem that is mounted read-only? (a later remount rw would flush
> those, right?)
In general it's possible for fsck to potentially modify a filesystem
such that it will confuse a kernel which is actively accessing the
filesystem, yes. It's rare, as discussed above, but it's
theoretically possible. What's **really** bad is that if the file
system is mounted read-only, and then remounted read/write, it's
possible that there are cached file system data structures (block
group descriptors, inodes, etc) which were incorrect, and fixed by
fsck --- but the kernel doesn't know that they were modified, and if
the file system is remounted r/w, the incorrect cached version could
get written back to disk, thus undoing the good work of the fsck.
> Second, in what is listed above as "Pass 1b", the low-level fsck needs to
> make the decision of which filesystem to check if multiple are candidates
> for precautionary checking and it must scan all filesystems on the
> spindle. If a system is restarted very infrequently and fsck always goes
> for the first candidate (perhaps the one with lowest pass number), the
> situation could arise that earlier filesystems might *always* consume the
> precautionary check, and later filesystems might starve. Alas, only the
> low-level fscks will have information on the last time a filesystem was
> checked (I would use greatest time since last check divided by check
> interval, followed by amount over maximum mount count at first thought).
Yes, it's hard. If you have that many file systems such that this is
an issue, then I suggest you use LVM and use LVM snapshots.
In any case, this is not something that *I* plan to do anything with,
simply because I have much higher priority things to do with my time.
If this is important, you'll have to do it or pay someone to do it, or
try to trick someone else into doing it.
- Ted
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
