Re: Single root filesystem evilness decreasing in 2010? (on workstations)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
thib wrote:
>> You trust ext4, and so does Ubuntu. Others (including most distros,
>> including Debian) do not.
>
> I'm sorry if I should know, but is that a clear position or the general
> fear around delayed allocation?
google "ext4 kde4" and the first hit is "Data loss may occurr when using
ext4 and KDE 4". I think Ubuntu offered ext4 as optional then and many
people ran into problems, supposedly massive data loss. XFS would be the
same. Application programmers don't cope with delayed allocation, and
since you cannot fix all the apps, you'd be stuck with the problem.
Apart from specific technical issues, there's general conservatism, most
of all in Debian.
> I'd say that I only trust it for its
> own integrity management, not that of my data. I don't think anyone
> should expect that from a filesystem, that's, to my knowledge, what
> databases are for.
That's a very interesting point. Filesystems *not* responsible for data
integrity? Whow. While I do get the idea (move integrity checking up to
higher-level structures to improve thruput), and I am sure it will speed
things up greatly when it works, doesn't this require all your software
to first be rewritten to take care of it?
>>> * Specific mount options
>>> mount(8) --bind won't allow me to set
>>> specific options to the remounted tree, I wonder if this limitation can
>>> possibly be lifted.
>> I have not heard of any way around it, and since you find it annoying,
>> that speaks against your single filesystem plan.
>
> Yep; but that's not right, I don't see how it can't be possible.
> Can somebody recommend me where I could forward this discussion? The
> kernel lists? I'm not sure.
Your request is perfectly reasonable. It is clearly possible in theory,
and I believe some Unix OS actually have it (don't know which though).
It is actually required for some backup schemes (which hence don't work
under Linux).
Quick googling gave me http://lwn.net/Articles/281157/ where they say
the limitation exists up to 2.6.25 kernels (the article is from 2008
though).
> I
> actually managed to dig a benchmark, yes. Shown a greater hit than that
> (I won't brag) but when you think about it, you'd really have to torture
> the filesystem to see it.
Possible. I'd like to see it; I don't know any LVM benchmarks,
unfortunately.
> sequential read
> at the beginning of the disk can be twice as fast as at the end?
Sure. That's not fiddling with individual sectors and 3D coordinates on
the HDD, but simply using partitions at the beginning of the disk. If
you care about a factor 2, then do partition it.
> I think everybody should keep a handy recovery live CD around; in fact,
> one would have enough with a separate partition only if the GRUB
> LVM/RAID modules break - if the core breaks, it's of no help.
Good point. A recovery CD obsoletes recovery partitions sometimes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkuLDAwACgkQ+VSRxYk440+bOwCfRowkIKWB4cp6yB9muuzm9KfJ
HEcAoLLPlH2C3HvedpvawNsH4uAvMJZX
=//v/
-----END PGP SIGNATURE-----
Reply to: