Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a device that mounts its root file system using NFS. On my NFS server I have a file representing the device's file system, namely target.ext2, which I mount on the appropriate /export directory.

I would like the device to be able to write on the mounted directory, but didn't want that the changes made to it to be propagated to the target.ext2 file. Is it possible?

share|improve this question

3 Answers 3

up vote 1 down vote accepted

Sorry I missed this question in the past... Try using a "Fanout" filesystem which will allow you to mount an "image" and then overlay a writable file-system on-top of the non-writable image. All writes to the drive will result in the "modifications" being done to the overlaying filesystem instead of the base-iamge. mini-fo is one such filesystem which will allow you to do this.

share|improve this answer
    
That's what I was after. mini-fo is quite old and seems unsupported. I couldn't compile it against my kernel (2.6.35) and I read that it was replaced by UnionFS in OpenWRT. In ended up using aufs which is replacing UnionFS. –  Thiago Figueredo Cardoso Apr 14 '11 at 21:43

If you are willing to reconsider a change in your architecture, you should be able to get something like that using a logical volume instead of a loopback file.

If you want to give it a try, first convert your file to a logical volume:

lvcreate -n original -L 20G vg0 # assumes 20G size and a valid 'vg0' volume group
dd if=/root/original.loopback of=/dev/vg0/original

Then create a snapshot:

lvcreate -s -n volatilecopy -L 2G /dev/vg0/original

Now you can mount /dev/vg0/volatilecopy and "write" up to 2GB on it without running into problems, yet /dev/vg0/original will remain unchanged.

Afterwards:

lvremove /dev/vg0/volatilecopy
lvcreate -s -n volatilecopy -L 2G /dev/vg0/original

Gives you a clean state again.

Advantages over copying the file over and over again: this uses less space (you only need extra space for the writes) and is quicker.

share|improve this answer
    
This is a good approach comparing to copy a file, but using a "fanout" filesystem is just what I was after. Thanks anyway! –  Thiago Figueredo Cardoso Apr 14 '11 at 18:02
    
Yes, I see what you mean - it's the right approach, I'm glad @TheCompWiz brought it up! –  Eduardo Ivanec Apr 14 '11 at 18:05

Not to my knowledge, short of a custom script that is called to reset the image from a master copy and remounting.

Any particular reason you want to allow writes to a folder without propagating the changes back to the file system? Seems it would easier to make the file system read-only, and then have the users write elsewhere for changes that should be kept.

share|improve this answer
    
I thought of a script like you said, but wondered if I could do this with mount options. I want to be able to play around on the device, but didn't want to save those changes. Sort of a RAM disk. –  Thiago Figueredo Cardoso Apr 11 '11 at 15:20
    
Not directly via nfs, however why not just make a copy of the image, play around then restore the image? Or do you mean, you want to consistently be able to workaround without saving changes? –  rfelsburg Apr 11 '11 at 15:33
    
It's a valid approach, but I didn't want to be "managing" the files. –  Thiago Figueredo Cardoso Apr 12 '11 at 17:53

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.