Issue 87: What happens when OHSM is not disabled and volume is Unmounted
Reported by rishi.b....@gmail.com, Jul 15, 2009
What will happen if someone does not diable the OHSM and unmounts the volume ?

Moreover what will happen if he again mounts the same volume 9and same
mount point) but does not enable OHSM ?
Jul 15, 2009
Project Member #1 imreckless@gmail.com
Sam table will be lost. If he again mounts the same volume
it will find flag unset, will call normal ext2 functions.
So ohsm needs to be enabled after remounting.
Jul 15, 2009
Project Member #2 sandeepksinha
Guys think in the direction of these two informations.
1. ohsm_sb
2. ohsm_enabled.

1. Once the file system e unmounted, your pointer should go NULL.
I am making an assumption, is that true?

2. If the FS is mounted back and OHSM is not enabled, then remember that our code in
FS is protect across checks for ohsm_enable. This will allow the file system to work
in a normal way, just like when OHSM is disbaled.

I mean we need some more clarity on this. But this definitely is an issue.

Now to what Rohit mentioned, 
We never loose the SAM table. till the module is not unloaded. Yes, after remounting
it will get the ohsm_enable flag as unset and hence no issues.

But yes, how can he enable that again, OHSM still has ohsm_enable as set. We will
soon be using some flags from the File system as an indicator. At will serve us with
the same purpose.
  
Labels: target-Release2.0
Jul 15, 2009
Project Member #3 imreckless@gmail.com
We will loose the sam table, it resides in ext2 itself, 
so unmounting the fs will result in loss of sam table.
So u have to enable ohsm to fill in the sam table after a remount.

Here an issue remains with the ohsm_enable flag, 
when you remount, the ohsm flag will be set, and it will
allocate through ohsm_ext2_new_blocks() which will again hav 
trouble finding the table as it is lost, no entries and there goes the ENOSPACE.

Jul 15, 2009
Project Member #4 sandeepksinha
we need to think on this seriously. I don't see a easy way until we tweak the file
systems unmount code.
Let keep this as an action item and take this at priority.
Remember we have to first be able to stabilize a single OHSM instance and then only
we can even think of a scale out.
Jul 15, 2009
Project Member #5 checkout...@gmail.com
I don't think there would be any issues to it.
See first of all whole OHSM is coded at the very best.

Now, answering why won't be there any issues.

See, talking first of ohsm_sb, it is pointer which points to the superblock of the
mounted file system and it is set every time ohsm is enabled.

If in case a user remount the file system without enabling OHSM, then the address of
this pointer would neither be set nor unset it will store the old value.
whereas nd.path.mnt->mnt_sb would change. It would be hold a new address.

and in ext2 we have added checks that ohsm_sb == superblock of the filesystem, which
would never match.

So, any file created would go for default allocation.
Status: Review-Req
Jul 16, 2009
Project Member #6 sandeepksinha
BUt how would OHSM be aware that there is a remount. I mean, if someone tiers to
re-enable the file sytsem, since, the ohsm_enabled flag will be set, it would always
fail.

Right? So, how about having a ohsm -e -f ... a forced enable or a re-enable.
We can document that after a remount,the user will have to do a force enable or a
re-enable which will force OHSM to restart.
Jul 17, 2009
#7 rishi.b....@gmail.com
replying to vineet's comment

checking the (ohsm_sb == superblock) will solve the issues but in the very rare case
this check will fail because the same address can be given to another mounted file
system's super block
Labels: -Type-Info Type-Defect