MESSAGE
| DATE | 2015-06-24 |
| FROM | Ruben Safir
|
| SUBJECT | Re: [NYLXS - HANGOUT] something strange a coworker did in fstab
|
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.
|
|
