On Wednesday, 8 November 2006 00:49, Alasdair G Kergon wrote: > On Wed, Nov 08, 2006 at 12:05:49AM +0100, Rafael J. Wysocki wrote: > > But freeze_bdev() is supposed to return the result of get_super(bdev) > > _unconditionally_. Moreover, in its current form freeze_bdev() _cannot_ > > _fail_, so I don't see how this change doesn't break any existing code. > > For example freeze_filesystems() (recently added to -mm) will be broken > > if the down_trylock() is unsuccessful. > > I hadn't noticed that -mm patch. I'll take a look. Up to now, device-mapper > (via dmsetup) and xfs (via xfs_freeze, which dates from before device-mapper > handled this automatically) were the only users. Only one freeze should be > issued at once. A freeze is a temporary thing, normally used while creating a > snapshot. (One problem we still have is lots of old documentation on the web > advising people to run xfs_freeze before creating device-mapper snapshots.) > > You're right that the down_trylock idea is more trouble than it's worth and > should be scrapped. Well, having looked at it once again I think I was wrong that this change would break freeze_filesystems(), because it only calls freeze_bdev() after checking if sb->s_frozen is not set to SB_FREEZE_TRANS (freeze_filesystems() is only called after all of the userspace processes have been frozen). However, XFS_IOC_FREEZE happily returns 0 after calling freeze_bdev(), apparetnly assuming that it won't fail. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel