Strange /dev/loop behavior

Strange /dev/loop behavior

[Byron Stanoszek]

Over the months using kernels 2.2 and 2.4, I've seen some inconsistencies with
the behavior of syncing data to filesystems mounted via loopback.

Say I mounted a 32MB 'diskimage' file as ext2fs. My goal is to be able to make
changes to this filesystem, 'sync' these changes, and then copy a compressed
version of the filesystem via the network for a diskless machine to boot. This
has to take place without unmounting the filesystem.

When we started with Linux 2.2 in June 1999, I was able to use this script to
accomplish the task:

# cat diskimage | gzip > diskimage.gz

Starting with 2.2.17, it became evident that the file 'diskimage' in cache was
not equivalent to the filesystem mounted loopback. The script was changed to
the following to reflect that it was the device data itself that needed to be
compressed:

# cat /dev/loop0 | gzip > diskimage.gz

Now last week we've upgraded these servers to 2.4 (2.4.9-ac7 specifically) and
it appears that /dev/loop0 is inconsistent with the actual loopback filesystem
contents (even after a 'sync'). The inconsistency is intermittent. Sometimes
the script works, sometimes the data in the modified files on the diskless
machine is corrupt, and it requires a second cat|gzip to fix.

I've changed the script to use 'cat diskimage' again for the meantime, but I
don't know if it's the absolute fix.


Is there any known method of copying/compressing the loopback-mounted file-
system that always guarantees consistency after a sync, without requiring the
fs to be unmounted first?

Thanks,
 Byron

-- 
Byron Stanoszek                         Ph: (330) 644-3059
Systems Programmer                      Fax: (330) 644-8110
Commercial Timesharing Inc.             Email: byron@comtime.com

Re: Strange /dev/loop behavior

[Ignacio Vazquez-Abrams]

On Fri, 14 Sep 2001, Byron Stanoszek wrote:

> Is there any known method of copying/compressing the loopback-mounted file-
> system that always guarantees consistency after a sync, without requiring the
> fs to be unmounted first?

Try mounting the loop device synchronously (mount ... -o sync).

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: Strange /dev/loop behavior

[Pavel Machek]

Hi!

> > Is there any known method of copying/compressing the loopback-mounted file-
> > system that always guarantees consistency after a sync, without requiring the
> > fs to be unmounted first?
> 
> Try mounting the loop device synchronously (mount ... -o sync).

That should not be needed. All data should be on disk by time umount
succeeds. That's not currently the case, and that's a bug.
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: Strange /dev/loop behavior

[Eric W. Biederman]

Byron Stanoszek <gandalf@winds.org> writes:

> Is there any known method of copying/compressing the loopback-mounted file-
> system that always guarantees consistency after a sync, without requiring the
> fs to be unmounted first?

Mounting read-only and then syncing might do it.  Going directly to
the block device on 2.4.x is not supported when the filesystem is
mounted.  This is because the page cache is not coherent with the
block cache, and there are now plans to make this the case.   In
general this won't work anyway because some other program might 
be modifying your fs while you read the block device.

Eric

Re: Strange /dev/loop behavior

[Ignacio Vazquez-Abrams]

On Sat, 15 Sep 2001, Pavel Machek wrote:

> Hi!
>
> > > Is there any known method of copying/compressing the loopback-mounted file-
> > > system that always guarantees consistency after a sync, without requiring the
> > > fs to be unmounted first?
> >
> > Try mounting the loop device synchronously (mount ... -o sync).
>
> That should not be needed. All data should be on disk by time umount
> succeeds. That's not currently the case, and that's a bug.

The message reads as though he wants the data to be on-disk without requiring
a umount.

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>