Solved Changes of the Timestamps

Hello Guys !!

My apologize for a question that I've already discussed with you a lot of times.
Here, I try to pose the topic in a different point of view.

As you know, once a file stored into a drive is opened, the Last Modified Date changes (is updated).

The question is:

are these changes due to a writing operation of the OS'es device driver into the filesystem or maybe to a self-updating operation due to the interface's firmware (usb/sata), that overwrite the timestamps field of the filesystem ?

In other words: is there a real writing operation by an external agent (OS'es device driver) into the filesystem or maybe is an internal updating operation managed by the interface's firmware, consequent to the execution of the "open" function ?


Bye !!!!
 
As you know, once a file stored into a drive is opened, the Last Modified Date changes (is updated).
Only if you actually wrote to the file. If you only open it the Last Access time is updated (unless the filesystem is mounted with noatime).

are these changes due to a writing operation of the OS'es device driver into the filesystem or maybe to a self-updating operation due to the interface's firmware (usb/sata), that overwrite the timestamps field of the filesystem ?
No, it's the filesystem driver that does this because it's a function/feature of a filesystem. If you circumvent the filesystem driver and modify the file's content directly on disk (by accessing the data blocks) the timestamps won't be changed.
 
No, it's the filesystem driver that does this because it's a function/feature of a filesystem.

Hello Sir,

my apologize ... with: O.S. device diver I meant exactly what you've better specified: the filesystem driver (loaded into the OS).

So, if I've well undersytood, what happens is a real writing operation managed by the filesytem drive into the Last Access time field of the filesystem (obviously, unless the filesystem is mounted with noatime).

Is it so ?

If it is so, the usb/sata interfaces (better usb/sata protocols) have only a "media communication function" finalized to transport informations between the PC and the drives and they have no role related to possible writing operations into the drives.

Is it correct ?

So one of my previous frequent questions posed here: "can a usb/sata interface does writing operations into attached drives" has conceptually no sense. It is strongly wrong.
Is it so ?

Bye !
 
If you circumvent the filesystem driver and modify the file's content directly on disk (by accessing the data blocks) the timestamps won't be changed.

circumvent the filesystem driver ?
accessing data blocks ?
o_Oo_O

Could be useful for some cases (e.g. accessing filesystem types that aren't supported in the kernel).
Really there are special files in the directory /dev that allow direct access to the disk, but these entries have permissions that only allow access by root. The only way for unprivileged processes to access the disk is via the filesystem interface, which includes permission management.

Which FreeBSD system calls allows to circumvent the filesystem driver (at kernel level) ? I think open(), read(), write() ...

Please, can you better detail your assertion with an example ?

What do you think about the following approach to reading a file (circumventing filesystem driver):

Code:
fd = sys_open(filename, O_RDONLY, 0);
if (fd >= 0) {
  /* read the file here */
  sys_close(fd);
}


Thanks in advance.
 
Layers. Ogres have layers (look up the movie quote, it's funny). You need to learn about layers. Seriously, your questions are making less and less sense, because you first need to understand a little bit about how storage devices (disks) and file systems work.

At the bottom, there are storage devices (like disk drives and USB sticks). They are typically connected via interfaces like USB or SATA. The operating system exposes them as devices, for example "/dev/da1". The only thing one can do with these devices is read or write "blocks" (often called sectors), with typically block sizes being 512 and 4096. The device driver for these devices is the thing that connects the physical piece of hardware to the computer's operating system, and takes read and write requests on /dev/da1 and executes them against the hardware.

Obviously, all modern storage devices (whether they are spinning disks or flash storage, whether connected via SCSI, SATA or USB) has internal firmware. For the purpose of this discussion, that is irrelevant: the storage device itself can only store blocks of a fixed size, and those blocks can only be read or written.

A storage device itself has no concept of modification time. The USB or SATA driver doesn't think about modification times or access time or owner or permissions or anything like that. As you wrote, the permissions that are set by the operating system make it so only root can read or write these devices. In practice, that matters very little, since block devices are very rarely used directly by programs (the rare examples are things like gpart).

How do you access a block device? You can use the low level API (open(), read(), write(), close(), and so on), or the high level API (fopen(), fread(), fwrite() ...); those two are in effect the same, since the higher-level API simply uses the lower-level one. In C, just do "fd1 = open("/dev/da1", O_RDWR)" or something like that, and you get a descriptor you can read and write to. On OSes where there is a difference between block and character devices, you can only read some of them in multiples of the block size and on block boundaries; FreeBSD doesn't make that distinction.

The next layer up is the file system. It is usually inside the kernel (although there are userspace file systems, such as the ones that use the FUSE kernel adapter). Sometimes people call the file system code the "driver", which isn't all wrong, but also not particularly helpful. Because it is in the kernel, it doesn't have to worry about things like permissions. It takes one (or more) storage devices and exposes them using file system interfaces, using user-accessible objects like files and directories. Being in the kernel, it can expose these objects with interesting ownership and permissions. The file system implements these objects having attributes, such as files typically having names (there is not always a 1-to-1 correspondence between files and names, but usually), having permissions and owners, and then the modification and access times you talk about. So the piece of code that implements a specific file having an mtime or an atime is the file system, and has absolutely nothing to do with USB, SATA, or the block device. Now, the various attributes (like names, permissions, times) need to be stored somewhere, which is in blocks of the underlying block device, just like file data.

You can also access file with the same APIs, using open() or fopen(): "fd1 = open("/home/ralphbsz/testfile.txt", O_RDWR)" and so on. Again, they amount to the same.

The file system has rules about when the time (a.k.a. modification time) and time (a.k.a. access time) of files and directories are updated. For example, if you open it with O_RDWR and write to it, the mtime will be updated. If you open it in any fashion and read from it, the atime will be updated. There are borderline cases (like for example: you open for RDWR, but then only read), and directories also have time stamps, and I can't remember which time will be updated in which case for those. If you really need to know, the POSIX standard is online and defines this super accurately.

As SirDice correctly pointed out, people who are criminally insane can read and modify file content by reading and writing the storage device directly, and that will obviously not modify any time stamps. They could even do crazy things like reading file system metadata (like the mtime!), and with enough evil intent even modify it. People who do this are either nuts and need to put into an asylum, or a geniuses and need to be given an award, or both. In practice, this just doesn't happen.

Last hint: On nearly all file systems, you can turn of atime (access time) updates. This makes sense, because then just reading a file doesn't change the state of the file system, and it makes things much more efficient. The atime is really an artifact from the bad old days when we didn't have real HSM systems, and is rarely needed today, so one should turn it off. On some file systems you can even turn of mtime updates; that doesn't give you much extra efficiency, and seems like a dubious idea in general.
 
Hei ralph,
thanks very much for your reply.

I'm so sorry for my always less and less sense questions.

Please, let me write other (probably) less sense sentencies, related on the dangerous action of mounting a filesystem.


- "mounting a file system with the "ro" option doesn't guarantee that a kernel driver will not write to a corresponding block device"

- "ro options don't protect Ext3/4 file systems against automatic orphan inodes deletion performed by a kernel driver on a "read-only" file system and there is no explicit mount option to disable orphan inodes deletion"

- "At present, it's known that Ext3/4 drivers will transfer an error code recorded in the journal (indicating a fatal error occurred within the file system) to the superblock even if the underlying block device is read-only"


My no sense questions are addressed to understand if the FreeBSD natively overcome these problems (related to the Linux word).

I cannot say more.

Thanks thanks.

Bye !
 
- "mounting a file system with the "ro" option doesn't guarantee that a kernel driver will not write to a corresponding block device"
- "ro options don't protect Ext3/4 file systems against automatic orphan inodes deletion performed by a kernel driver on a "read-only" file system and there is no explicit mount option to disable orphan inodes deletion"
- "At present, it's known that Ext3/4 drivers will transfer an error code recorded in the journal (indicating a fatal error occurred within the file system) to the superblock even if the underlying block device is read-only"
All this may be true. And why do you care?

Look at it this way. What is the state of a file system? It is that total of everything that can be observed about a file system. How do you observe a file system? By reading it. You can read directories (that's done with the readdir() system call, which is fundamentally what the ls program does), you can read the content of files (see above: open() followed by read()), and you can read the attributes of files and directories (like owner, mtime, ACL, ...) with various flavors of the stat() call. The read-only option on mount works correctly if the state of the file system does not change. None of these operations change the state of the file system (with the exception of read operations updating the atime, which is turned off by the "ro" option on mount).

There are operations that do change the state of a file system: writing to files, creating new files, deleting files, renaming things, changing attributes. None of those operations are possible when the file system is mounted "ro".

The stuff you are complaining about is internal to the file system. You should not concern yourself with it. As far as the user of a file system is concerned, it is "ro" if the state doesn't change; internally the file system could compress all the data, copy it in cuneiform to a clay tablet, and throw the spinning platter coated with rust away, and it would still be read-only. Let me give you a concrete example: Imagine a file system that has built-in RAID functionality (ZFS is one example), and that is mounted read-only. You are reading from it. Such file systems are typically always "scrubbing" the disk, so even if you are not reading from it, it will internally be reading. While reading, it discovers a problem: perhaps a bad sector, or a checksum error, or a failing disk. The RAID part of the file system will now move data around to non-broken hardware, reconstruct unreadable data from its redundant copies, and restore balance by making sure all disks are evenly loaded. This involves a heck of a lot of writing to the hardware, yet from the user's standpoint, the file system is read-only.

Remember, in the previous lesson I said that you have to think in layers? A file system is a layer in the software stack. It has an upper boundary, which is where user processes use calls like open(), read(), readdir(), stat() to read and write things, and it is at that upper boundary that the "ro" switch applies. It also has a lower boundary, where it interacts with the block storage layer below (some file systems, such as NFS, don't use block storage, but instead use a server, and other file systems are more complex and use multiple storage devices plus networking). Whether the file system reads or writes on the lower boundary is none of your business as a user of a file system. If you were an implementor of file systems, you might worry whether it is a good or bad idea to modify the underlying block devices. You also would need to learn to deal with block devices that are not writable at all. Such things exist, but they are rare, the only example I know within normal stock BSD and Linux distributions are the CD-ROM / DVD file systems (iso96something and UDF).
 
ralph = the beautiful mind !!!

It is the reply that I was looking for.

Wonderfull, effective and brilliant the interpretation of the functioning of a filesystem in terms of "status" in which it "lives". For me, the only true way to understand in detail its dinamic functioning.

Congratulations.

Thanks very much.
 
Back
Top