On Wed, Feb 9, 2011 at 3:34 AM, <[email protected]> wrote: > > Jeff Hanson: >> The aufs mount point. That is what the users will be working with. > > Do you mean only the directory? > If so, aufs does copyup the dir only, and I don't think it fills up the > rw branch. >
mount -v -t aufs -o br:/home/administrator/.wine-Diablo_II_rw=rw:/srv/wine/.wine-Diablo_II=ro none /home/administrator/.wine-Diablo_II chown -R administrator:administrator /home/administrator/.wine-Diablo_II > >> "Some" is the problem. I can't predict which files out of the ro > ::: > > Right. "How many files will be copied-up?" will be a problem. > But I don't think the problem will be solved even if aufs supports > uid-mapping (or faking). > I don't fully understand how aufs handles ownership and permissions. From what Mike said it seems it just passes them through from the branch filesystems. What happens if the same file exists in two ro branches and they have different ownership? Does the order of the branches when mounting determine which one gets priority in the mount point? >> Using Diablo II (http://en.wikipedia.org/wiki/Diablo_II) as an example > ::: > > Ok, you don't want to spend 11GB, and you could reduce to 2.3GB by > mounting aufs for each user. > Correct. It saves space and with some scripting it should save deployment time also. >> Next I need to install a popular mod, Median XL > ::: > > Ok, you made changes to the original Diablo II files with changing the > dir. While I don't know where the original ~wineadmin/.wine-Diablo_II > went, but I hope users who are playing Diablo II right now can keep > playing. > The shared copy is now in /srv/wine and users don't have access to the original in /home/wineadmin. I just moved the original so I can reuse the same path for a new mount point. The goal is to get the "diff" of the original Diablo file structure (now mounted through aufs from /srv/wine) and Median XL in the new rw branch. > By the way, if you want, you may be able to provide both of the original > Diablo II and Median XL-ed one by aufs. > > - you already have $srv/Diablo_II which contains the original > one. create a new $srv/Diablo_II_Median_XL with keeping $srv/Diablo_II > unchanged. > mkdir $srv/Diablo_II_Median_XL > mount -t aufs -o br:$srv/Diablo_II_Median_XL:$srv/Diablo_II \ > none $srv/Diablo_II_Median_XL > (apply Median XL and the changed files are stored in > $srv/Diablo_II_Median_XL) > mount -o remount,ro $srv/Diablo_II_Median_XL > (now you have $srv/Diablo_II and $srv/Diablo_II_Median_XL which are to > be shared and provied to users. and $srv/Diablo_II_Median_XL holds > the "diff from the original" only) > > - provide users the original. > mount -t aufs -o br:~user/Diablo_II:$srv/Diablo_II none ~user/Diablo_II > > - provide users the Median XL-ed one. > mount -t aufs -o br:~user/Diablo_II_Median_XL:$srv/Diablo_II_Median_XL \ > none ~user/Diablo_II_Median_XL That is another way of doing the same thing I described. I think I used the copy approach because I was concerned that the .wh.* files in the rw branch would cause problems if the branch was reused as an ro branch. > Additionally, because you may want to keep the shared files unchanged, > there are options to make them readonly. For example, make an ext2 > image. > dd if=/dev/null of=Diablo_II.ext2 bs=... count=... > mkfs -t ext2 Diablo_II.ext2 > mount -o loop Diablo_II.ext2 /mnt > cp -pr $srv/Diablo_II /mnt > umount /mnt > losetup -r /dev/loop0 Diablo_II.ext2 > mount -o ro /dev/loop0 $srv/Diablo_II > Now you have $srv/Diablo_II dir from a single file Diablo_II.ext2. And > the mount option 'ro' is specified. Also /dev/loop0 is bound as readonly > too (losetup -r). So under $srv/Diablo_II no one can make modification > even if you set all permissions to world-writable. > Of course, you can make any filesystem instead of ext2. You may want to > try isofs, squashfs or something. > That is not something I though of and may solve my problem. It could also allow me to use squashfs to reduce the size further. ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
