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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
