1 |
Ok, |
2 |
|
3 |
I'm really new to loopback devices / filesystems, so please forgive me |
4 |
if I'm doing something stupid here. It wouldn't be the first time. :/ |
5 |
|
6 |
I've created this loopback filesystem, by using `dd if=/dev/zero |
7 |
of=individual.files.img` (so named because I'm hope to copy a bunch of |
8 |
"individual files" onto it) so that it is 65gig in size and I've |
9 |
attached it to a loopback device and formatted it with a filesystem. |
10 |
So far all seems good and I can write files to it and seem to be able |
11 |
to read the changes & stuff. |
12 |
|
13 |
I've mounted CD .iso images loopback in the past to access the files |
14 |
on them, but this is the first time I've created one from scratch and |
15 |
written files to it, so I was actually quite chuffed when fsck |
16 |
actually performed its magic. |
17 |
|
18 |
This kinda illustrates the problem I'm having: |
19 |
|
20 |
$ date |
21 |
Sun Dec 6 23:54:32 GMT 2009 |
22 |
$ ls -lh individual.files.img |
23 |
-rw-rw-rw- 1 stroller users 65G 2009-12-06 23:36 individual.files.img |
24 |
$ ls -l mnttmp/ |
25 |
total 0 |
26 |
$ sudo losetup -a |
27 |
$ sudo losetup /dev/loop0 individual.files.img |
28 |
$ sudo losetup -a |
29 |
/dev/loop/0: [0811]:132155 (/path/to/individual.files.i*) |
30 |
$ sudo ntfs-3g /dev/loop0 mnttmp/ |
31 |
$ ls -l mnttmp/ |
32 |
total 1 |
33 |
-rwxrwxrwx 1 root root 11 2009-12-06 23:52 foo |
34 |
$ cat mnttmp/foo |
35 |
wowow wow |
36 |
$ echo bar >> mnttmp/foo |
37 |
$ cat mnttmp/foo |
38 |
wowow wow |
39 |
bar |
40 |
$ sudo sync |
41 |
$ sudo umount -v mnttmp/ |
42 |
/dev/loop0 umounted |
43 |
$ ls -l mnttmp/ |
44 |
total 0 |
45 |
$ sudo sync |
46 |
$ sudo losetup -d /dev/loop/0 |
47 |
$ sudo sync |
48 |
$ ls -lh individual.files.img |
49 |
-rw-rw-rw- 1 stroller users 65G 2009-12-06 23:36 individual.files.img |
50 |
$ date |
51 |
Sun Dec 6 23:57:05 GMT 2009 |
52 |
$ sudo losetup -a |
53 |
$ |
54 |
|
55 |
|
56 |
So ISTM that the above proves that the filesystem *thinks* it's |
57 |
written the file to disk (because I can modify the file contents and |
58 |
read back the changes), but that the loopback file hasn't actually |
59 |
been written, *because the file modification date doesn't change*. |
60 |
|
61 |
I'm really seeing the evidence of this, because individual.files.img |
62 |
is shared over NFS and I then try to mount the image loopback on |
63 |
another machine (running System Rescue CD) it doesn't see the changes |
64 |
I've made. If I reattach the image loopback on the first system again, |
65 |
the changes *are* still shown. I figured that the system must |
66 |
"somehow" be caching the results, so a little Google (is a dangerous |
67 |
thing) and that's what led me to try running sync repeatedly to try |
68 |
flushing to disk. But as you can see, that's not helping. |
69 |
|
70 |
The filesystem on which individual.files.img is stored is running on a |
71 |
3ware RAID controller, but that is set with caching off (for this array) |
72 |
|
73 |
I'm pretty much stumbling around in the dark here, so any pointers |
74 |
would be very gratefully received. I feel like I could spent a load of |
75 |
time trying different things and not have any luck. For instance I've |
76 |
just noticed that /etc/exports I have (async) set as an option, so |
77 |
maybe that's preventing the second system from seeing the changes on |
78 |
the NGS mount; but then if the file's timestamp hasn't changed, then |
79 |
there surely won't be any changes to read. It's like the computer is |
80 |
only _pretending_ to write out to the loopback device. |
81 |
|
82 |
Anyway: I'm an idiot, one of the experts on the list will surely see |
83 |
in an instant what obvious thing I'm overlooking. |
84 |
|
85 |
Thanks, |
86 |
|
87 |
Stroller. |