I can't seem to find an answer to this question. I'd just like to understand how one single OS can implement and run (support) multiple file systems?
Assume that there's a global name-space where all file and directory names have some sort of prefix to determine which file system the file or directory is from. For some operating systems (DOS) the prefix might be a device letter (e.g. the C:\ at the start of C:\foo\bar.txt). For other operating systems it might look like a normal part of the file's path (e.g. the /home at the start of /home/foo/bar.txt/ might tell the OS that the file is in the file system mounted at /home).
Once the OS has figured out which file system contains the file it can ask that file system about the file using the remaining part of the file's "global name" (e.g. for the file /home/foo/bar.txt it'd ask the file system mounted at /home for the file /foo.bar.txt).
To allow this to work there will be a layer built into the OS to register file systems and figure out which file system to ask about which file or directory (likely in addition to providing other features - e.g. caching directory info and file data). Often (but not always) this is called "the Virtual File System" (or VFS).
During boot, and when a new storage device is plugged in, there will be "something" to figure out which type of file system to use and how it will be added to the global name space. This can include auto-detection (e.g. from partition table entries on the storage device), a set of rules for removable media, and/or a configuration file (/etc/fstab).
The basic function of a file system is to provide the mapping to translate virtual blocks into logical blocks (or in ye olde days, physical blocks). For a file system, the operating system has to implement a translation system that will convert virtual block N of a file into logical block Q on the disk.
There is nothing that prevents an operating system from having multiple subsystems for performing that translation in different ways corresponding to multiple file systems.
Most operating systems have some kind of MOUNT command that tells the operating system to connect to a disk and determine what kind of file system it has. It is during the mount process that the operating system selects the appropriate virtual to logical translation software to use.
Operating system has supported multiple file systems from the beginning. In ye olde days, there were 9-track tapes with their own file systems in addition to disks. The operating system had to support those as well.
Related
I have a database on "Microsoft OneDrive", I have 4 valid licenses from Gupta 4 SqlBase. When I try to run from PC 1 I can access the database, but when I try the same from PC 2 I got this
Reason: Attempting to open an existing file and a failure has occurred.
Remedy: Determine and correct the cause of the open file failure.
Verify that the specified file exists. Verify the number of
files allowed open for the operating system permits the
additional file, that is, check the FILES= configuration
parameter setting.
I assume this is related to the LOG files on the database and some settings in the Sql.Ini, but I'm not able to find where/how???
The intention is to run the database on "OneDrive", buy SqlBase licenses and run a multi user system. The application has been made as such.
Where do I think wrong?
Where do I do wrong?
What setting are missing?
Thanks
That won't work.
SqlBase (and all other RDBMS) are built to manage one databasefile + logfiles.
When multiple instances work with more or less replicated datafiles this ends up in a clash.
There are systems in the world which can work as a distributed cluster (e.g. like the document-database RavenDB) but they are built to work like this (not with OneDrive of course but with their own replication mechanism). Sqlbase is not.
My question is how operating system loads
User space application to RAM. I know how
Bootloader works when we first turn computer on Bios simply reads 512 kb data till aa55 bootloader signature and loads bootloader to ram. Do regular userspace programms are handled in this way? If yes how? Because bootloader activated by bios and how user space program handled by operating system? More specifacally how execv() load program to RAM and start execution point for user space ?
Thanks in advance
Userspace programs are not handled like the bios, the Kernel will be involved in running a userspace program.
In general:
When a program is executed in shell, the shell will invoke system calls to create a new task in a new address space, read in the executable binary, and begin executing it.
To understand the details, you need to understand:
The elf format. Of course there are also other formats which can be used in Linux, elf is just the most common one, and a good starting point. Understanding elf will help you understand how the kernel loads the executable binary into memory precisely.
Linux process management; this will help you to understand how a program starts to run.
Reading the related codes in the kernel. fs/exec.c will be of great help.
The procedure varies among operating systems. Some systems have a background command interpreter that exists through the life of a process and within the process itself. When a program is run, the command interpreter stays in the background (in protected from user mode access). When the program completes, the command interpreter comes to the foreground and can run another program in the same process.
In the Eunuchs-world, the command interpreter is just a user-mode program. Whenever it runs a program it kicks off another process.
Both of these types of systems use a loader to configure the process address space for running a program. The executable file is a set of instructions that define how to lay out the address space,
This is significantly different from a bootloader. A bootloader blindly loads a block of stored data into memory. A program loader contains complex instructions for laying out a process address space that include handling shared libraries and doing address fixups.
I am learning to write character device drivers from the Kernel Module Programming Guide, and used mknod to create a node in /dev to talk to my driver.
However, I cannot find any obvious way to remove it, after checking the manpage and observing that rmnod is a non-existent command.
What is the correct way to reverse the effect of mknod, and safely remove the node created in /dev?
The correct command is just rm :)
A device node created by mknod is just a file that contains a device major and minor number. When you access that file the first time, Linux looks for a driver that advertises that major/minor and loads it. Your driver then handles all I/O with that file.
When you delete a device node, the usual Un*x file behavior aplies: Linux will wait until there are no more references to the file and then it will be deleted from disk.
Your driver doesn't really notice anything of this. Linux does not automatically unload modules. Your driver wil simply no longer receive requests to do anything. But it will be ready in case anybody recreates the device node.
You are probably looking for a function rather than a command. unlink() is the answer. unlink() will remove the file/special file if no process has the file open. If any processes have the file open, then the file will remain until the last file descriptor referring to it is closed. Read more here: http://man7.org/linux/man-pages/man2/unlink.2.html
After creating the boot loader, if I copy the bytes of the boot loader and paste it on the 1st 512 bytes of the pen drive using a hex editor, will it work? (Actually I want to learn creating an operating system from scratch.)
I'm not entirely sure I understand your question, but to answer the title: yes. You can write to any part of the drive with an appropriately-designed hex editor with appropriate permissions (usually "sudo" access is required on Linux).
For instance, writing to the boot sector of a flash drive is necessary for automating booting of the CHDK system.
Not all hex editors are designed to access drives, some can only work with files. For instance, the NCurses Hexeditor normally works only with files, but can be made to access disks as files in Linux/Unix environment by employing the -d flag.
The Linux dd command also enables low-level writing to drives. This may be useful in your case as it can be used to perform byte-by-byte copies of drive contents, including MBR sections.
Do not know about HEX editors, but looks like on Windows you can try to CreateFile with name like this \\.\PHYSICALDRIVE0 or just \\PHYSICALDRIVE0. And alter them with WriteFile (with caution!!! otherwise you can damage your OS install or other data).
You can probably figure out device name with WinObj. Also take a look at this project and this question.
Does File and Registry redirection happen on registry hives and files of offline windows installations? Meaning that 32-bit programs see a different view of the filesystem / registry on a 64-bit systems even though it is not the running operating system?
No, if you're digging around on another disk whose operating system isn't running, you won't see file redirection