Hi folks,
> 2) Would it be difficult to implement "freeze" of
> ext3 filesystem - that is, blocking all I/O to the
> filesystem until it's "unfrozen" (XFS can do
> that), for two purposes :
> A/ allowing "freezing" in a clean state, to allow clean snapshotting
> B/ allowing "freezing" while moving a SCSI disk or a network-connected
> disk without umounting filesystem
> This is already done, and is used by the LVM/device
> mapper subsystem to do snapshots of the filesystem. > However, I'm not sure if there is a user-space API
> to access this.
Yes, there exists a function "freeze_bdev()" in fs/buffer.c which freezes the file system on the specified block device without unmounting. If the file system is "ext3" then, it calls journal_lock_updates()" to ensure that no more transactions take place. "thaw_bdev()" is its counterpart to continue operations.
You can provide an ioctl call in fs/ext3/ioctl.c which will look like :
{
sb = freeze_bdev(bdev);
/* do your stuff */
thaw_bdev(bdev, sb);
return 0;
}
>From user land you can always call this ioctl routine.
> 3) Is it possible to allow data to stay in the
> journal for a very long time ?
> Yes, this can be done (I think) by tuning the journal
> flush time and having a large enough journal to avoid
> filling it up. However, I don't think this would be
> practical because the only common way to do
> this would be e.g. flash memory and the heavy usage
> of the journal would quickly wear out such devices,
> and it would also be slow.
This ca be done by changing the commit interval of the journaling thread viz. "kjournald". By default it is 5 seconds but you can change its value by changing JBD_DEFAULT_MAX_COMMIT_AGE. But, if a inode is being used as journal log then, there are chances of journal running out of blocks. So it is better to experiment this with an auxiliary device for external journal log.
- Nitin
_______________________________________________
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users
