On Wed, Apr 19, 2017 at 1:53 PM, JD <jd1008@xxxxxxxxx> wrote: > Could you explain what the journal is holding: The User Data, the Metadata, > or Both? By default, the journal contains an abbreviated representation of the metadata. Faster to write, faster to read, than fs metadata. But it requires interpretation and reconstruction with existing filesystem metadata in order to mean anything. The idea of a journaled file system is for metadata to be consistent, unambiguous, but possibly stale. If there's a crash, the file system does not need to be fsck'd because the file system isn't damaged, it's just stale, so journal replay will bring it up to date. A sync on a journaled file system means data and journal get committed; metadata can be stale. Either remoun-ro or umount or freeze will also cause metadata to be current before those commands complete. > If both, should not a sync clear the contents of the journal after the > completion of a sync (assuming no other io operation was done after the > sync)? No. > If not both (i.e. ONLY metadata), then replaying the journal only preserves > the metadata that describe the files (name, mode, ...etc). Generically, the journal gets a write intent, sync, the data is written, sync, and then the journal updated to indicate the write happened, sync, and then fs metadata is updated, and then the journal entry is obsoleted, and then the super block is updated. Something like that; and that's where all file systems end up having variable problems and come up with different solutions, is that the hardware often lies about having committed writes to stable media. And this can lead to out of sequence writes, and that leads to confusion if there's a crash. The other thing that's really complicated about filesystems is understanding a huge pile of it is in RAM. There's the in RAM state, and there's the on disk state, and there's the "in-flight" state as the file system is flushing to disk. And anyway it's really complicated shit and totally amazing any of it works at all. > > Another question: What if the FS is mounted with the SYNC option in fstab, > such as: > UUID=71af3828-c4cd-2d26-b1f7-8337def05b8c /sdd1 ext3 sync,rw 0 0 > > Would that cause immediate commit of the DATA, or would that cause the > commit of the METADATA? sync looks like it's not filesystem specific, and it looks like it's a buffered write bypass - HUH. That's interesting for a different reason. I'm kinda perturbed at the moment about writes to USB sticks where a 1GiB file copy takes like 2 seconds to complete and isn't cancellable in any meaningful way. Of course what's happened is the file is just being cached, claimed to be done copying, and yet it's bleeding slowly onto the USB stick. But all indications in GNOME are that the copy is done, which is just wrong. I wonder if sync would fix that. Well what do you know, it does. And it makes it really f'n slow as well. I'm getting 203KiB/s writes. This flash drive should write at 10-20MB/s. So it sounds like it's doing a massive amount of metadata updating, that's totally unusable (for a flash drive anyway). But interesting test. -- Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
