Stephen Powell wrote:
Actually, that could be an important clue. Perhaps the "last mount date"
is what is being updated. And since both mounts were on the same day,
the date did not change. But if you reboot tomorrow ...
I don't know if that's it, of course. It's just a theory at this point.
The trouble with diagnosing something like that is that you can only
run one test per day (unless you mess with the system clock).
You can find the ext3_super_block data structure in linux/ext3_fs.h[1], line
444 in current mainline 2.6.
I noted:
...
__le32 s_mtime; /* Mount time */
/*30*/ __le32 s_wtime; /* Write time */
__le16 s_mnt_count; /* Mount count */
...
__le16 s_state; /* File system state */
...
/*40*/ __le32 s_lastcheck; /* time of last check */
...
/*88*/ char s_last_mounted[64]; /* directory where last mounted */
...
__le64 s_mmp_block; /* Block for multi-mount protection */
...
* The mount time is set by cpu_to_le32(get_seconds()) in fs/ext3/super.c
l1326, so it stores a timestamp in seconds (sorry Stephen). cpu_to_le32()
just byte swaps to little-endian if necessary, in case you're wondering.
* The write time is actually the time the superblock itself was last
written. Explanation in fs/ext3/super.c l2366:
/*
* If the file system is mounted read-only, don't update the
* superblock write time. This avoids updating the superblock
* write time when we are mounting the root file system
* read/only but we need to replay the journal; at that point,
* for people who are east of GMT and who make their clock
* tick in localtime for Windows bug-for-bug compatibility,
* the clock is set in the future, and this will cause e2fsck
* to complain and force a full file system check.
*/
if (!(sb->s_flags & MS_RDONLY))
es->s_wtime = cpu_to_le32(get_seconds());
* The "state" is a quite vague term, at least at first glance. Possible
values seem to be:
#define EXT3_VALID_FS 0x0001 /* Unmounted cleanly */
#define EXT3_ERROR_FS 0x0002 /* Errors detected */
#define EXT3_ORPHAN_FS 0x0004 /* Orphans being recovered */
It should then not change during normal operation.
* Apparently, the time of last check and the last mounted directory are
never touched by the kernel. Might want to investigate userspace mount(8).
BTW, 64 bytes max for the entire path? Really? :/
If you ever try to mount a filesystem in a deep hierarchy, you might want to
remember this if something goes haywire.
* I don't know what the block for multi-mount protection is, I just
mentioned it in case it's some kind of lock to prevent multiple mounts, in
which case it would updated at each mount (but why store that on-disk?)
Never touched by the kernel itself either.
-
Maybe I missed something relevant.
[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=include/linux/ext3_fs.h;hb=HEAD
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b981d6c.8040...@stammed.net
