lkml.org 
[lkml]   [2010]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectApparent non-sync related to CF+(u)mount

Greetings,

I've ran into a strange problem that (to me) seems to be around the kernel.

Nutshell description: when using CF (compact flash) remount read-only
does not flush to the card, only umount does.

Detailed description:

I have a lot of systems that boot from CF cards. Been doing that for
years. Most of the system is on read-only mounted partitions. I have
integrity checks based on the hash of the read-only partitions. The
problem I ran into comes when I update the system. What I expect is that
after 'remount read-write' -> update -> 'remount read-only' (-> and a
safety sync, practice from old-old times), the hash should be stable for
the partition. What I found is that after reboot the hash changes and
becomes stable from there. I tracked the change down to the umounting on
a CF card.

So here is the 'hash history':

Before mount: old hash
After mount read-only: old hash
After update+remount read-only: new intermittent hash
After umount (or reboot for a system): new hash

I did several tests with:
- HDD
- Loopback device
- CF on ATA
- CF on USB reader
- USB flash drive
- Different CF manufacturers and products
- Different filesystems (xfs, ext3, vfat)
- Different kernels (and even distros)
- Sync()
- Waiting times after remount

The only combination that manifests the effect is any that has CF and
change only happens at umount.

Tests were made at least on the following kernel versions:
- 2.6.32-24-generic, 32 bit (Ubuntu 10.04LTS)
- 2.6.33, 64 bit (Vanilla, Slackware current)
- 2.6.35.22, 64 bit (Ubuntu 10.10)

It's 100% reproducible.

There is either some badly cached, unwritten data somewhere ('badly'
means that reading back from the device should give the right data
regardless of it being written out or not). It's not (just) inode
related or alike as I found from the following test:

Made a 200MB partition and used a 10MB random data written to a file as
'update'. I did a dd copy of the partition after the partition was
remounted read-only and after umount. Doing a cmp on the two images gave
me a bit over 10MB of difference. This was more or less expected as I
noticed that umounting after update always takes time while with non-CF
media only the remount does.

It might or might not be related, but the first differing byte is at
48kiB+1.

Any ideas where the problem lies? As the behavior itself is out of
ordinary I tried to make various tests but I may have missed some still.

Regards
Bgs




\
 
 \ /
  Last update: 2010-11-22 17:57    [W:0.021 / U:0.852 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site