[Gllug] Hacker Attack, and a wild aside about version-controlled filesystems

[Nix]

On Wed, 11 Jan 2006, Bruce Richardson yowled:
> On Wed, Jan 11, 2006 at 12:28:39PM +0000, Nix wrote:
>> On Tue, 10 Jan 2006, Bruce Richardson yowled:
>> > Actually, that is not a reassuring statement.  What I described was a
>> > little more than the ability to compile a kernel.  People who assume
>> > that this is enough are a real problem.  Managing production systems is
>> > about more than basic technical ability.
>> 
>> Indeed. The signs of a first-rank sysadmin are three, I think:
>> 
>> - ability to work with others (at least other sysadmins ;) )
>> - the aforementioned technical ability (Larry Wall's `laziness',
>>   too; it doesn't matter if you've got technical ability if you
>>   never use it to automate anything)
>> - paranoia! Assume everything will go wrong. Hunt ceaselessly
>>   for points of failure and plug them. Assume everything is your
>>   enemy and is out to get you.
> 
> A good Sysadmin is also going to consider, before making a change, not
> just what it achives in the short term but how maintainable it is in the
> long term (and maintainable by other people, not just by him/her, so
> this is more than just "benign laziness").  That includes considering
> how reproducible the change is, how it affects recovery strategies etc.

Yes. I'll admit that I'm not very good at that: I tend to assume that
other people will be able to at least read documentation, rather than
guessing that they know how something works, panicking, making changes
at random, and stuffing it up.

This turns out to be true only in rare cases. Perhaps my documentation
is unclear...

> This should be the case even with office infrastructure but even more so
> in a production environment where uptime (and SLAs, very likely) are a
> factor.  In that scenario, the restrictions imposed by such a change are
> likely to affect the need for downtime in case of change, for example.

Oh boy yes, although if someone else has fucked up badly enough the
clients may actually be *asking* you to take it down as long as it
means they'll get it back faster. (If *you* have fucked up that badly,
well, it's time to look for a new job. I've had to recover from this
twice and in each case the idiot who did it was in a different job
by the end of the year... :/ )

> People who know how to compile kernels but don't consider the
> implications of installing them have caused me quite specific pain in
> the relatively recent past.

Specifically, `if this kernel doesn't work, can we roll back?'

[wild aside]


I'm thinking a lot about revertability right now 'cos of my current
spare-time obsession. I've just completed the design of a
PostgreSQL-backed, version-controlled FUSE-based filesystem I'm calling
Recant. Coding is underway as of three hours ago :)


Despite the version control, the design has it being fully POSIX- and
Linux-VFS-compliant (well, as compliant as a FUSE filesystem can be),
with everything from hardlinks to xattrs supported, with the basis of
versioning being *both* the inode[1] *and* the filename, so editors that
work by unlink-and-rewrite still end up creating a new version.

Since it's not written yet I don't know how slow it will be, but I've
got several ideas for trading off time for space if I need to. Making a
new version is *much* more efficient than copying the file (incurring a
~200-byte overhead), which is a good thing 'cos you get a new version on
every close() or directory change (other than access time change of
course).

File access is, unfortunately, going to be slow, scaling as O(mn) where
m = the number of versions needed to traverse to reconstruct the file
contents, and n = the number of blocks in the file. However, blocks are
resized according to access patterns, and large blocks are automatically
compressed, and most files (being read and written linearly in huge
chunks) will end up with only a few big blocks, so there's not actually
much work to do in the majority of cases. I hope.

(The nice thing about making it PostgreSQL-backed is that network-
distribution of both the filesystem daemons and the underlying database
storage comes for free: I don't need to do anything. :) )


My goal is eventually to make it stable enough that I can store my home
directory in it :) other people store their home directories in lesser
version-control systems, and sacrifice nifty POSIX features. This is
not good enough for a true purist and maniac. Hence Recant.


[1] actually it's not an inode, it's a 64-bit entity called a uinode,
    translated on-the-fly to 32-bit inode numbers, so if you want stable
    inums across remounts, don't look here.

-- 
`I must caution that dipping fingers into molten lead
 presents several serious dangers.' --- Jearl Walker
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug