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