FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 12-06-2009, 11:42 PM
Stroller
 
Default Using losetup & loopback devices / filesystems - changes aren't written to disk?!?!?

Ok,

I'm really new to loopback devices / filesystems, so please forgive me
if I'm doing something stupid here. It wouldn't be the first time. :/


I've created this loopback filesystem, by using `dd if=/dev/zero
of=individual.files.img` (so named because I'm hope to copy a bunch of
"individual files" onto it) so that it is 65gig in size and I've
attached it to a loopback device and formatted it with a filesystem.
So far all seems good and I can write files to it and seem to be able
to read the changes & stuff.


I've mounted CD .iso images loopback in the past to access the files
on them, but this is the first time I've created one from scratch and
written files to it, so I was actually quite chuffed when fsck
actually performed its magic.


This kinda illustrates the problem I'm having:

$ date
Sun Dec 6 23:54:32 GMT 2009
$ ls -lh individual.files.img
-rw-rw-rw- 1 stroller users 65G 2009-12-06 23:36 individual.files.img
$ ls -l mnttmp/
total 0
$ sudo losetup -a
$ sudo losetup /dev/loop0 individual.files.img
$ sudo losetup -a
/dev/loop/0: [0811]:132155 (/path/to/individual.files.i*)
$ sudo ntfs-3g /dev/loop0 mnttmp/
$ ls -l mnttmp/
total 1
-rwxrwxrwx 1 root root 11 2009-12-06 23:52 foo
$ cat mnttmp/foo
wowow wow
$ echo bar >> mnttmp/foo
$ cat mnttmp/foo
wowow wow
bar
$ sudo sync
$ sudo umount -v mnttmp/
/dev/loop0 umounted
$ ls -l mnttmp/
total 0
$ sudo sync
$ sudo losetup -d /dev/loop/0
$ sudo sync
$ ls -lh individual.files.img
-rw-rw-rw- 1 stroller users 65G 2009-12-06 23:36 individual.files.img
$ date
Sun Dec 6 23:57:05 GMT 2009
$ sudo losetup -a
$


So ISTM that the above proves that the filesystem *thinks* it's
written the file to disk (because I can modify the file contents and
read back the changes), but that the loopback file hasn't actually
been written, *because the file modification date doesn't change*.


I'm really seeing the evidence of this, because individual.files.img
is shared over NFS and I then try to mount the image loopback on
another machine (running System Rescue CD) it doesn't see the changes
I've made. If I reattach the image loopback on the first system again,
the changes *are* still shown. I figured that the system must
"somehow" be caching the results, so a little Google (is a dangerous
thing) and that's what led me to try running sync repeatedly to try
flushing to disk. But as you can see, that's not helping.


The filesystem on which individual.files.img is stored is running on a
3ware RAID controller, but that is set with caching off (for this array)


I'm pretty much stumbling around in the dark here, so any pointers
would be very gratefully received. I feel like I could spent a load of
time trying different things and not have any luck. For instance I've
just noticed that /etc/exports I have (async) set as an option, so
maybe that's preventing the second system from seeing the changes on
the NGS mount; but then if the file's timestamp hasn't changed, then
there surely won't be any changes to read. It's like the computer is
only _pretending_ to write out to the loopback device.


Anyway: I'm an idiot, one of the experts on the list will surely see
in an instant what obvious thing I'm overlooking.


Thanks,

Stroller.
 
Old 12-07-2009, 01:48 AM
Albert Hopkins
 
Default Using losetup & loopback devices / filesystems - changes aren't written to disk?!?!?

I tried repeating your experiment, sans NFS and NTFS, and while I did
note that the modification timestamp on the file did not change, the
contents of the file did (i.e. the filesystem changed).

FWIW this is Debian bug #459703 (Google told me that).

What I'm going to guess is happening in your instance is the NFS server
is caching parts of the file, and it checks the timestamp to see if the
cache is dirty. Since it doesn't see that file file is modified it
assumes its cache isn't dirty and continues to use it.

You could possibly get away with it by simply

# touch individual.files.img

Maybe, maybe not.


Also, usually you don't need to use losetup unless you are using
encryption or offsets or something else exotic. Usually

# mount -o loop my.img /mnt/pt

Will do the trick.
 
Old 12-14-2009, 08:30 AM
Stroller
 
Default Using losetup & loopback devices / filesystems - changes aren't written to disk?!?!?

On 7 Dec 2009, at 02:48, Albert Hopkins wrote:

...
I tried repeating your experiment, sans NFS and NTFS, and while I did
note that the modification timestamp on the file did not change, the
contents of the file did (i.e. the filesystem changed).

FWIW this is Debian bug #459703 (Google told me that).

What I'm going to guess is happening in your instance is the NFS
server
is caching parts of the file, and it checks the timestamp to see if
the

cache is dirty. Since it doesn't see that file file is modified it
assumes its cache isn't dirty and continues to use it.

You could possibly get away with it by simply

# touch individual.files.img

Maybe, maybe not.



As part of my scheduled maintenance I upgraded my kernel this weekend.
Since I took a little flack a week or two ago for using a .config
plagarised from the Knoppix liveCD, this time I stole one from
systemrescuecd-x86-1.3.1.iso (in fact this is also what I was using
for the NFS client which was able to previously access the loopback
disk image just fine).


Now it's working perfectly, and I'm unable to reproduce the problem.

Many thanks for your help, and I'm sorry I'm unable to document this
issue further,


Stroller.
 

Thread Tools




All times are GMT. The time now is 11:08 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org