Re: Proposed git tree changes.

On 27 Jan 2012, Nigel Cunningham outgrape:

> Hi.
>
> On 28/01/12 02:08, Nix wrote:
>> On 26 Jan 2012, Nigel Cunningham verbalised:
>>> Well, I did quietly put them all on Github the other day. Quietly
>>> because I wanted to wait until I'm happy with the kernel source first.
>>> Right now, it's not working right on my new Sandybridge based laptop and
>>> I'm getting disk corruption. Don't want to inflict that on anyone else.
>> 
>> Hm. It's not universal, FWIW (or at least I hope it isn't: I suppose
>> that depends how subtle the disk corruption is!)
>
> Is corruption ever subtle?

Oh yes. I've seen single-bit-flips in the journal causing all sorts of
hell -- though this is not common. That's why all my important data
these days is stored on a PCIe system with ECCRAM. Checksums everywhere.

>                            I'm seeing my /home filesystem (ext4, options
> rw,relatime,errors=remount-ro,user_xattr,acl,barrier=1,data=ordered,
> which I assume are the defaults because I don't think I've messed with
> them) abort and need a fsck.

Ow! Well, I'm happy/afraid that I'm unlikely to see this, since the
system I suspend has its /home mounted on NFS from the aforementioned
ECCRAM/PCIe box, so rarely has outstanding writes when it's suspended:
there are lots of writable filesystems, but other than /var they're
rarely written to. (Heck, isn't the first thing suspension does a sync
anyway? How *could* there be anything outstanding causing a journal
abort? The journal should have been flushed by the time you suspend...)

I'm wondering if something is mounting the fs before resume happens.
Note that even a readonly mount will do a journal replay, so you have to
avoid even that. (But you know that. Still there should probably be a
bigger warning in Documentation/power/tuxonice.txt that if your root
filesystem is ext3 or ext4, you *must* resume from an initrd or
initramfs, not from an early boot script before read-write remount.)

But I've only done two suspend/resume cycles in 3.2 so far. So maybe
disk-corruption fun is awaiting me after attempt three! ... hm, maybe
it's time to run a backup. :)

-- 
NULL && (void)