MESSAGE
| DATE | 2015-06-24 |
| FROM | Paul Robert Marino
|
| SUBJECT | Re: [NYLXS - HANGOUT] something strange a coworker did in fstab
|
No in this case its an old fashioned path to a partition in /dev and
there are some reasons for this because its a VM in the cloud the
UUID's aren't always a reliable method for certain block storage
types.
here seems to be the sticking point.
in the mount(2) man file the third sentence under DESCRIPTION says
"
Since Linux 2.4 a single file system can be visible at multiple mount
points, and multiple mounts can be stacked on the same mount point.
"
I suspect that the reason this support may be related to user
mountable clustered and network file systems, but im not sure,
On Wed, Jun 24, 2015 at 5:53 PM, Ruben Safir wrote:
>
> On 06/24/2015 05:24 PM, Paul Robert Marino wrote:
>> thanks Rubin
>>
>> By the way i have to correct my self it turns out he used XFS not EXT4
>> but I doubt that was built into XFS. while there is a clusterd version
>> of XFS (CXFS) it uses a IP based distributed lock servers to
>> coordinate all of the locks, similar to VCFS, or Storenext
>> (incidentally Ive been told that all there were originally written by
>> group of brothers). its very different than GFS2 in because it does
>> its lock server IPC in a portion of the volume not over IP.
>>
>> On Wed, Jun 24, 2015 at 4:13 PM, Ruben Safir wrote:
>>> On 06/24/2015 04:00 PM, Paul Robert Marino wrote:
>>>> its ext4
>>>>
>>>> On Wed, Jun 24, 2015 at 3:09 PM, Ruben Safir wrote:
>>>>> On 06/24/2015 03:06 PM, Ruben Safir wrote:
>>>>>> On 06/24/2015 01:25 PM, Paul Robert Marino wrote:
>>>>>>> hello every one
>>>>>>>
>>>>>>> one of my coworkers did something very odd in fstab it seam to be
>>>>>>> working but i have this nagging feeling about it and wanted to know if
>>>>>>> any one can think of a good reason other than the obvious ones not to
>>>>>>> do it.
>>>>>>>
>>>>>>> here is what he did he put entries in fstab to mount /dev/sdb1 on /srv
>>>>>>> and /db both set to mount on boot
>>>>>>> it seems to be working the only odd thing seems to be that df only
>>>>>>> shows the results for the first entry in mtab
>>>>>>>
>>>>>>> I seem to remember being told back in the 90's that it was a really
>>>>>>> bad idea but I cant remember why other than the obvious that its dam
>>>>>>> confusing and a symlink can serve the same effective function.
>>>>>>>
>>>>>> That is the file system? You should only be able to double mount with a
>>>>>> unified
>>>>>> file system. It won't be good for your symbolic links.
>>>>>>
>>>>>> Ruben
>>>>>>
>>>>> your going to have a locking and race condition problem unless the FS
>>>>> supports this.
>>>>> That would suck for a database.
>>>>>
>>>>> Ruben
>>>
>>> that is not safe, to my understanding. The problem is locks and
>>> deadlocking actually. When a process is waiting for the drive it sleeps
>>> until the drive comes back. If you have two processes going after the
>>> same shared resource, in this case a file on a file system, they need
>>> to know when writes and reads are taking place otherwise they can access
>>> the same resource simutaeously and end up with an HW aerror and file
>>> corruption, or otherwise get in a cycle of waiting for file access that
>>> will never happen, which is deadlocking.
>>>
>>> There has to be proper coding to handle this position so unless the FS
>>> is designed to handle this, it shouldn't work. At minimum you wind up
>>> with errors.
>>> See Critical Area programming. I actually think I have notes on this in
>>> my graduate school OS class.
>>>
>>> BTW - threading makes this a complete disaster.
>>>
>>>
>
>
> Actually, there is one other thing to consider with this. The naming
> conventions have
> changed for partitions. If the OS is keeping track of partitions by UID
> or GUID when
> lables can be added, in which case /dev/sda1 might be just a lable. I'm
> not even sure
> how the OS handles that.
>
>
|
|
