On Wed, Jan 21, 2015 at 03:04:02PM +0800, Miao Xie wrote: > > Pending changes are *not* only mount options. Feature change and label change > > are also pending changes if using sysfs. > > My miss, I don't notice feature and label change by sysfs. > > But the implementation of feature and label change by sysfs is wrong, we can > not change them without write permission. Label change does not happen if the fs is readonly. If the filesystem is RW and label is changed through sysfs, then remount to RO will sync the filesystem and the new label will be saved. The sysfs features write handler is missing that protection though, I'll send a patch. > > For freeze, it's not the same problem since the fs will be unfreeze sooner or > > later and transaction will be initiated. > > You can not assume the operations of the users, they might freeze the fs and > then shutdown the machine. The semantics of freezing should make the on-device image consistent, but still keep some changes in memory. > >>> For example, if we change the features/label through sysfs, and then umount > >>> the fs, > >> It is different from pending change. > > No, now features/label changing using sysfs both use pending changes to do the > > commit. > > See BTRFS_PENDING_COMMIT bit. > > So freeze -> change features/label -> sync will still cause the deadlock in the > > same way, > > and you can try it yourself. > > As I said above, the implementation of sysfs feature and label change is wrong, > it is better to separate them from the pending mount option change, make the > sysfs feature and label change be done in the context of transaction after > getting the write permission. If so, we needn't do anything special when sync > the fs. That would mean to drop the write support of sysfs files that change global filesystem state (label and features right now). This would leave only the ioctl way to do that. I'd like to keep the sysfs write support though for ease of use from scripts and languages not ioctl-friendly. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
