linux-kernel - Re: The ext3 way of journalling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 8 Jan 2008 18:40:14 +0000 (UTC)
From:	Tuomo Valkonen <tuomov@....fi>
To:	linux-kernel@...r.kernel.org
Subject:  Re: The ext3 way of journalling

On 2008-01-08, Andre Noll <maan@...temlinux.org> wrote:
> It's not a workaround. The ext3 maintainers argue that every file
> system should be checked from time to time. Therefore it's the
> default. You do not agree with them, so change the default and be
> happy. 

The thing is, I agree with them (although the default intervals could
be a bit longer), but it gets confused and thinks it's been years since
last check, when it hasn't. I have my doubts that Theodore Tso's reply
is the problem here, because I didn't use to have this problem; it 
appeared relatively recently. But maybe old versions of e2fsck were
smarter...

> Use the time you are currently using for whining on mailing lists.

That's doable on time you'd spend idling anyway. There are only so
many hours of the day that you can do work that demands considerable
thinking.

> Then write a set of udev rules for your SCSI devices. It's easy.

It isn't. There's no simple pre-existing setting to edit. And besides,
it's the wrong approach from the POV of clean consistent design. It's
the kludged worse-is-better approach that results in unusable 
clusterfucks.

> If you're not willing to compile, you'll have to use what other
> people provide. It's your choice, but at least there _is_ a choice.

I'd compile, if the thing to be compiled weren't made uncompilable.
I'd use pre-compiled shit, if it wasn't shit.

> I tend to disagree. It's not hard at all to configure a kernel if
> you know the hardware. It's even easier if you already have a working
> config for some kernel version. Just use "make oldconfig" to upgrade
>=66rom one version to the next as already suggested by others and me.

It didn't use to be hard for 1.2 or so, but it's been constantly getting
worse, along with all the bloat. 

>> And then there's the problem that the "good" driver for my SATA disk
>> may not be there anymore in the latest kernels, and so on.
>
> That is clearly a regression and I'm sure Jeff and other maintainers
> of the driver would be interested in details on this matter.

I don't know the details; all I know is that I've heard that the old
SATA drivers that appear as /dev/hd$PREDICTABLE are being obsoleted in
favour of those that appear as /dev/sd$RANDOM along with all the USB
devices and whatnot.

-- 
Tuomo

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/