MESSAGE
| DATE | 2015-06-25 |
| FROM | Ruben Safir
|
| SUBJECT | Re: [NYLXS - HANGOUT] something strange a coworker did in fstab
|
On 06/24/2015 07:30 PM, prmarino1-at-gmail.com wrote:
> 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.
>
https://groups.google.com/d/msg/comp.os.linux.misc/4YRJVgnBj0M/gH63hbw0gmQJ
> 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.
> "
>
>
>
>
> 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.
>>
>>
>
|
|
