MESSAGE
| DATE | 2015-06-25 |
| FROM | Ruben Safir
|
| SUBJECT | Re: [NYLXS - HANGOUT] something strange a coworker did in fstab
|
On 06/24/2015 07:13 PM, Paul Robert Marino 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.
>
>
> 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.
Ummm
I'm quite certain that still needs mutual support by the file system.
In fact, that was the reason for the UFS which drove me crazy until I
understood it and then tore up the US and reinstalled that asus eeepc.
This is an excellent question for comp.os.linux.hardware and
comp.unix.programmer
The last group has a lot of people in it that know the code base and
specs very well.
the specification for write is listed in unistd.h
361
362 /* Write N bytes of BUF to FD. Return the number written, or -1.
363
364 This function is a cancellation point and therefore not marked with
365 __THROW. */
366 extern ssize_t write (int __fd, const void *__buf, size_t __n) __wur;
I haven't found the code itself though. I am reading notes on access()
and other places though, that make it pretty clear that the directly is
known by a passed variable. It does not seem to know inferently what it
is writing to so it does not inherenelty know what is it blocking.
Writing to the file system itself is a protected kernel security
application. The unistd.h in the kernel source is not that useful. It
is all constants.
>>>
>>> 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.
>>
>>
> .
>
|
|
