Hi Mulyadi,
These are the sequence of commands i used..
dd if=/dev/zero of=./fsimage.img bs=1k count=10000
/sbin/losetup /dev/loop0 ./fsimage.img
/sbin/mke2fs /de/loop0 10000
mkdir mntpoint
mount /dev/loop0 ./mntpoint
cd mntpoint
vim newfile
/* entered some contents, saved and exited*/
cd ..
rm fsimage.img
cd mntpoint
/* I am now able to change to this directory ! */
cat newfile
/* the contents are here without any change ! */
Hi Sergei,
Thank you for ur explanation.. Please find my doubts inline...
2009/1/4 Sergei Trofimovich <[email protected]>:
> On Sun, 4 Jan 2009 18:39:10 +0530
> "Paraneetharan Chandrasekaran" <[email protected]> wrote:
>
>> Hi All,
>> I created a file of 10 MB from /dev/zero using dd command.
>> Then i associated /dev/loop0 to that file using losetup command. Then
>> i created an ext2 filesystem above /dev/loop0 using mke2fs command.
>> Then i mounted the that loop device in a mount point. I entered the
>> monted directiry and created on file and entered some contents to that
>> file. Then i came out of the directory. Then i deleted the file i
>> associated. Then If i go inside the mounted directory, i was able
>> change the directory and the file was there with the contents i put.
>>
>> how is that possible when deleted the file itself inside which i
>> created the ext2 filesystem..? I was previously thinking that the VFS
>> reads from the file itself for files and directory info. is it not
>> like that..? I have even cleared the buffers after i deleted the
>> file(using sync).
>
> When you unlink file - directory entry(dentry) is deleted from directory
> structure immediately (metadata operation). So you can't open deleted file by
> it's old _name_.
>
> Inode (structure, holding info about physical blocks belonging to associated
> file) is
> deleted when there is no more references to it.
>
> References can be:
> * on disk (hard links)
> * in-memory descriptors (files currently opened by process(es))
>
> Thus you can safely use code like this:
> ...
> char tmpl[] = "/tmp/tmp.XXXXXXXX"
> int fd = mkstemp (tmpl); /* create inode and dentry */
> (assert fd != -1);
> unlink(tmpl); /* delete dentry */
>
> /*
> * Do something with fd: read/write
> */
>
> close(fd); /* delete inode */
> ...
>
> Moreover, you can get access to this (deleted) file until process exits or
> closes file.
>
> You could play with it (prompt 1 emulates losetup, prompt 2 emulates your
> actions):
> prompt1$ cat > /tmp/z
> FOO
> BAR
> <leave it running>
> prompt2$ rm /tmp/z
> $ls -l /proc/*/fd/* 2>/dev/null | grep /tmp/z
> l-wx------ 1 slyfox slyfox 64 Янв 4 18:39 /proc/22665/fd/1 ->
> /tmp/z (deleted)
> $ cat /proc/22665/fd/1
> FOO
> BAR
>
> But!.
>
> My examples are userspace reference holders and they are visible via
> /proc/*/fd,
> losetup (or mount -o loop), in contrast, increments reference count
> to associated file differently - via ioctl() call.
Does this mean loop device driver is holding another
reference in kernel space..?
>
> You can observe dark magic by `strace'ing losetup command:
>
> # strace losetup /dev/loop0 /etc/fstab
> ....
> open("/etc/fstab", O_RDWR|O_LARGEFILE) = 3
> open("/dev/loop0", O_RDWR|O_LARGEFILE) = 4
> ....
> ioctl(4, 0x4c00, 0x3) = 0 // ahha, that's it! We ask kernel
> to do something nasty with this descriptor
> close(3) = 0
> ioctl(4, 0x4c04, 0xbf9c0624) = 0 // and here too
> close(4) = 0
> ....
> /usr/include/linux/loop.h:#define LOOP_SET_FD 0x4C00
> /usr/include/linux/loop.h:#define LOOP_SET_STATUS64 0x4C04
>
> So, your ext image file will be deleted right after you supply losetup -d
> /dev/loop0 (or umount)
> Before this action you can play with /dev/loop .
>
I found an another observation too. Now i dint delete the
image file.. I opened the image file and searched for the contents i
put in that newly created file.. It was there in some corner.. Then i
closed the image file by ":q".. Then i added some more data in the
newly created file... Then i came back to the image file and searched
whether the newly added contents have reflected here or not.. Of
course, the newly added contents and old contents were in that image
file.. Then i was happy and closed by the image file by ":wq"..
Then i entered into the mounted directory and opened the file i
created.. I again entered some other contents. Then i came back to the
image file and opened it.. The changes are no longer there.. I again
and again added new contents in the file inside mount point.. The
changes were no longer in the image file.. But all the newly added
contents were not go into the air as i was able to see them in the
file inside the mounted directory forever..
summary: When the image file is closed with ":wq", the chages made in
the file inside mounted dir are no longer reflected. But the changes
and new additions are retained in the file inside mountpoint. where do
the contents are coming from..? and why this loop association goes
away when i close it with ":wq" ( writing in the iamge file des)?
Thanks,
Paraneetharan C
>>
>> Thanks in advance,
>> Paraneetharan C
>>
>
> --
>
> Sergei
>
