How do I implement a file system driver driver in Linux? [on hold]












14















Assume that I have invented a new file system, and now I want to create a file system driver for it.



How would I implement this file system driver, is this done using a kernel module?



And how can the file system driver access the hard disk, should the file system driver contain code to access the hard disk, or does Linux contain a device driver to access the hard disk that is used by all the file system drivers?










share|improve this question









New contributor




user343344 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











put on hold as too broad by Gilles, muru, Michael Homer, jimmij, msp9011 17 hours ago


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.























    14















    Assume that I have invented a new file system, and now I want to create a file system driver for it.



    How would I implement this file system driver, is this done using a kernel module?



    And how can the file system driver access the hard disk, should the file system driver contain code to access the hard disk, or does Linux contain a device driver to access the hard disk that is used by all the file system drivers?










    share|improve this question









    New contributor




    user343344 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.











    put on hold as too broad by Gilles, muru, Michael Homer, jimmij, msp9011 17 hours ago


    Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.





















      14












      14








      14


      1






      Assume that I have invented a new file system, and now I want to create a file system driver for it.



      How would I implement this file system driver, is this done using a kernel module?



      And how can the file system driver access the hard disk, should the file system driver contain code to access the hard disk, or does Linux contain a device driver to access the hard disk that is used by all the file system drivers?










      share|improve this question









      New contributor




      user343344 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.












      Assume that I have invented a new file system, and now I want to create a file system driver for it.



      How would I implement this file system driver, is this done using a kernel module?



      And how can the file system driver access the hard disk, should the file system driver contain code to access the hard disk, or does Linux contain a device driver to access the hard disk that is used by all the file system drivers?







      linux filesystems drivers






      share|improve this question









      New contributor




      user343344 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      share|improve this question









      New contributor




      user343344 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      share|improve this question




      share|improve this question








      edited yesterday









      Gilles

      544k12811021619




      544k12811021619






      New contributor




      user343344 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      asked yesterday









      user343344user343344

      762




      762




      New contributor




      user343344 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      user343344 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      user343344 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.




      put on hold as too broad by Gilles, muru, Michael Homer, jimmij, msp9011 17 hours ago


      Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.









      put on hold as too broad by Gilles, muru, Michael Homer, jimmij, msp9011 17 hours ago


      Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
























          4 Answers
          4






          active

          oldest

          votes


















          23














          Yes, filesystems in Linux can be implemented as kernel modules. But there is also the FUSE (Filesystem in USErspace) interface, which can allow a regular user-space process to act as a filesystem driver. If you're prototyping a new filesystem, implementing it first using the FUSE interface could make the testing and development easier. Once you have the internals of the filesystem worked out in FUSE form, you might then start implementing a performance-optimized kernel module version of it.



          Here's some basic information on implementing a filesystem within kernel space. It's rather old (from 1996!), but that should at least give you a basic idea for the kind of things you'll need to do.



          If you choose to go to the FUSE route, here's libfuse, the reference implementation of the userspace side of the FUSE interface.



          Filesystem driver as a kernel module



          Basically, the initialization function of your filesystem driver module needs just to call a register_filesystem() function, and give it as a parameter a structure that includes a function pointer that identifies the function in your filesystem driver that will be used as the first step in identifying your filesystem type and mounting it. Nothing more happens at that stage.



          When a filesystem is being mounted, and either the filesystem type is specified to match your driver, or filesystem type auto-detection is being performed, the kernel's Virtual FileSystem (VFS for short) layer will call that function. It basically says "Here's a pointer to a kernel-level representation of a standard Linux block device. Take a look at it, see if it's something you can handle, and then tell me what you can do with it."



          At that point, your driver is supposed to read whatever it needs to verify it's the right driver for the filesystem, and then return a structure that includes pointers to further functions your driver can do with that particular filesystem. Or if the filesystem driver does not recognize the data on the disk, it is supposed to return an appropriate error result, and then VFS will either report a failure to userspace or - if filesystem type auto-detection is being performed - will ask another filesystem driver to try.



          The other drivers in the kernel will provide the standard block device interface, so the filesystem driver won't have to implement hardware support. Basically, the filesystem driver can read and write disk blocks using standard kernel-level functions with the device pointer given to it.



          The VFS layer expects the filesystem driver to make a number of standard functions available to the VFS layer; a few of these are mandatory in order for the VFS layer to do anything meaningful with the filesystem, others are optional and you can just return a NULL in place of a pointer to such an optional function.






          share|improve this answer





















          • 1





            This is a pretty good answer though to fully answer the question as stated you'd also need to say a bit about the functionality the block device layer provides for the file system layer to build upon.

            – kasperd
            yesterday











          • I sort of alluded to that with the "here's a pointer to a standard block device" bit, but good point; I expanded on that.

            – telcoM
            yesterday











          • This answer, specifically the description of what happens in what order, is divine. Is there some sort of book/website I could read that has descriptions like that for all of "how linux works"?

            – Adam Barnes
            yesterday











          • You might be interested in Linux Kernel Internals or Linux Device Drivers, 3rd Edition. And of course, there's the option of reading the actual source code.

            – telcoM
            yesterday





















          4














          Yes a kernel driver can manage a file-system .



          The best solution to mock up , prototype a file-system is to use FUSE . And after you can think about transform it into a kernel driver .



          Wikipedia =>
          https://en.wikipedia.org/wiki/Filesystem_in_Userspace



          Source => https://github.com/libfuse/libfuse



          a tutorial => https://developer.ibm.com/articles/l-fuse/






          share|improve this answer































            0














            Yes this would typically be done using a kernel driver that can either be loaded as a kernel module or compiled into the kernel.



            You can check out similar filesystem drivers and how they work here.



            These drivers likely use internal kernel functions to access storage devices as blocks of bytes but you could also use blockdevices as exposed by drivers in the block devices and character devices folders.






            share|improve this answer








            New contributor




            Erik is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.




























              0














              You can use fuse, to make a user-land file-system, or write a kernel module.
              It is easier to do with fuse, as you have a choice of languages, and won't crash the kernel (and therefore the whole system).



              Kernel modules can be faster, but the first rule of optimisation is: Don't do it until you have tested working code. The second is like it: Don't do it until you have evidence that it is too slow. And the third: Don't keep it unless you have evidence that it makes it faster/smaller.



              And yes the kernel already has drivers for the hardware, you don't re-implement them.






              share|improve this answer
























              • There are major downsides to FUSE other than performance: it's hard to use it for your root filesystem. (Maybe possible with an initrd, but the FUSE binary couldn't be freed after booting because it would still be executing from the ramdisk.)

                – Peter Cordes
                yesterday






              • 1





                @PeterCordes It couldn't be freed, but that doesn't mean it can't be unlinked. If there's still a reference to it, it'll be kept in memory regardless of whether or not you left the initramfs and deleted the underlying binary.

                – forest
                19 hours ago











              • @forest: right, therefore you can't unmount the initrd after pivot_root, because there are still busy inodes in the initramfs.

                – Peter Cordes
                19 hours ago













              • A normal /init started from an initramfs will (I think) execve /init after pivot_root, to transfer control to the real root FS's /init. But a FUSE binary couldn't replace itself with execve if access to the root FS depended on the FUSE process responding to the kernel. Well maybe by priming the pagecache first, but that doesn't sound reliable.

                – Peter Cordes
                18 hours ago




















              4 Answers
              4






              active

              oldest

              votes








              4 Answers
              4






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              23














              Yes, filesystems in Linux can be implemented as kernel modules. But there is also the FUSE (Filesystem in USErspace) interface, which can allow a regular user-space process to act as a filesystem driver. If you're prototyping a new filesystem, implementing it first using the FUSE interface could make the testing and development easier. Once you have the internals of the filesystem worked out in FUSE form, you might then start implementing a performance-optimized kernel module version of it.



              Here's some basic information on implementing a filesystem within kernel space. It's rather old (from 1996!), but that should at least give you a basic idea for the kind of things you'll need to do.



              If you choose to go to the FUSE route, here's libfuse, the reference implementation of the userspace side of the FUSE interface.



              Filesystem driver as a kernel module



              Basically, the initialization function of your filesystem driver module needs just to call a register_filesystem() function, and give it as a parameter a structure that includes a function pointer that identifies the function in your filesystem driver that will be used as the first step in identifying your filesystem type and mounting it. Nothing more happens at that stage.



              When a filesystem is being mounted, and either the filesystem type is specified to match your driver, or filesystem type auto-detection is being performed, the kernel's Virtual FileSystem (VFS for short) layer will call that function. It basically says "Here's a pointer to a kernel-level representation of a standard Linux block device. Take a look at it, see if it's something you can handle, and then tell me what you can do with it."



              At that point, your driver is supposed to read whatever it needs to verify it's the right driver for the filesystem, and then return a structure that includes pointers to further functions your driver can do with that particular filesystem. Or if the filesystem driver does not recognize the data on the disk, it is supposed to return an appropriate error result, and then VFS will either report a failure to userspace or - if filesystem type auto-detection is being performed - will ask another filesystem driver to try.



              The other drivers in the kernel will provide the standard block device interface, so the filesystem driver won't have to implement hardware support. Basically, the filesystem driver can read and write disk blocks using standard kernel-level functions with the device pointer given to it.



              The VFS layer expects the filesystem driver to make a number of standard functions available to the VFS layer; a few of these are mandatory in order for the VFS layer to do anything meaningful with the filesystem, others are optional and you can just return a NULL in place of a pointer to such an optional function.






              share|improve this answer





















              • 1





                This is a pretty good answer though to fully answer the question as stated you'd also need to say a bit about the functionality the block device layer provides for the file system layer to build upon.

                – kasperd
                yesterday











              • I sort of alluded to that with the "here's a pointer to a standard block device" bit, but good point; I expanded on that.

                – telcoM
                yesterday











              • This answer, specifically the description of what happens in what order, is divine. Is there some sort of book/website I could read that has descriptions like that for all of "how linux works"?

                – Adam Barnes
                yesterday











              • You might be interested in Linux Kernel Internals or Linux Device Drivers, 3rd Edition. And of course, there's the option of reading the actual source code.

                – telcoM
                yesterday


















              23














              Yes, filesystems in Linux can be implemented as kernel modules. But there is also the FUSE (Filesystem in USErspace) interface, which can allow a regular user-space process to act as a filesystem driver. If you're prototyping a new filesystem, implementing it first using the FUSE interface could make the testing and development easier. Once you have the internals of the filesystem worked out in FUSE form, you might then start implementing a performance-optimized kernel module version of it.



              Here's some basic information on implementing a filesystem within kernel space. It's rather old (from 1996!), but that should at least give you a basic idea for the kind of things you'll need to do.



              If you choose to go to the FUSE route, here's libfuse, the reference implementation of the userspace side of the FUSE interface.



              Filesystem driver as a kernel module



              Basically, the initialization function of your filesystem driver module needs just to call a register_filesystem() function, and give it as a parameter a structure that includes a function pointer that identifies the function in your filesystem driver that will be used as the first step in identifying your filesystem type and mounting it. Nothing more happens at that stage.



              When a filesystem is being mounted, and either the filesystem type is specified to match your driver, or filesystem type auto-detection is being performed, the kernel's Virtual FileSystem (VFS for short) layer will call that function. It basically says "Here's a pointer to a kernel-level representation of a standard Linux block device. Take a look at it, see if it's something you can handle, and then tell me what you can do with it."



              At that point, your driver is supposed to read whatever it needs to verify it's the right driver for the filesystem, and then return a structure that includes pointers to further functions your driver can do with that particular filesystem. Or if the filesystem driver does not recognize the data on the disk, it is supposed to return an appropriate error result, and then VFS will either report a failure to userspace or - if filesystem type auto-detection is being performed - will ask another filesystem driver to try.



              The other drivers in the kernel will provide the standard block device interface, so the filesystem driver won't have to implement hardware support. Basically, the filesystem driver can read and write disk blocks using standard kernel-level functions with the device pointer given to it.



              The VFS layer expects the filesystem driver to make a number of standard functions available to the VFS layer; a few of these are mandatory in order for the VFS layer to do anything meaningful with the filesystem, others are optional and you can just return a NULL in place of a pointer to such an optional function.






              share|improve this answer





















              • 1





                This is a pretty good answer though to fully answer the question as stated you'd also need to say a bit about the functionality the block device layer provides for the file system layer to build upon.

                – kasperd
                yesterday











              • I sort of alluded to that with the "here's a pointer to a standard block device" bit, but good point; I expanded on that.

                – telcoM
                yesterday











              • This answer, specifically the description of what happens in what order, is divine. Is there some sort of book/website I could read that has descriptions like that for all of "how linux works"?

                – Adam Barnes
                yesterday











              • You might be interested in Linux Kernel Internals or Linux Device Drivers, 3rd Edition. And of course, there's the option of reading the actual source code.

                – telcoM
                yesterday
















              23












              23








              23







              Yes, filesystems in Linux can be implemented as kernel modules. But there is also the FUSE (Filesystem in USErspace) interface, which can allow a regular user-space process to act as a filesystem driver. If you're prototyping a new filesystem, implementing it first using the FUSE interface could make the testing and development easier. Once you have the internals of the filesystem worked out in FUSE form, you might then start implementing a performance-optimized kernel module version of it.



              Here's some basic information on implementing a filesystem within kernel space. It's rather old (from 1996!), but that should at least give you a basic idea for the kind of things you'll need to do.



              If you choose to go to the FUSE route, here's libfuse, the reference implementation of the userspace side of the FUSE interface.



              Filesystem driver as a kernel module



              Basically, the initialization function of your filesystem driver module needs just to call a register_filesystem() function, and give it as a parameter a structure that includes a function pointer that identifies the function in your filesystem driver that will be used as the first step in identifying your filesystem type and mounting it. Nothing more happens at that stage.



              When a filesystem is being mounted, and either the filesystem type is specified to match your driver, or filesystem type auto-detection is being performed, the kernel's Virtual FileSystem (VFS for short) layer will call that function. It basically says "Here's a pointer to a kernel-level representation of a standard Linux block device. Take a look at it, see if it's something you can handle, and then tell me what you can do with it."



              At that point, your driver is supposed to read whatever it needs to verify it's the right driver for the filesystem, and then return a structure that includes pointers to further functions your driver can do with that particular filesystem. Or if the filesystem driver does not recognize the data on the disk, it is supposed to return an appropriate error result, and then VFS will either report a failure to userspace or - if filesystem type auto-detection is being performed - will ask another filesystem driver to try.



              The other drivers in the kernel will provide the standard block device interface, so the filesystem driver won't have to implement hardware support. Basically, the filesystem driver can read and write disk blocks using standard kernel-level functions with the device pointer given to it.



              The VFS layer expects the filesystem driver to make a number of standard functions available to the VFS layer; a few of these are mandatory in order for the VFS layer to do anything meaningful with the filesystem, others are optional and you can just return a NULL in place of a pointer to such an optional function.






              share|improve this answer















              Yes, filesystems in Linux can be implemented as kernel modules. But there is also the FUSE (Filesystem in USErspace) interface, which can allow a regular user-space process to act as a filesystem driver. If you're prototyping a new filesystem, implementing it first using the FUSE interface could make the testing and development easier. Once you have the internals of the filesystem worked out in FUSE form, you might then start implementing a performance-optimized kernel module version of it.



              Here's some basic information on implementing a filesystem within kernel space. It's rather old (from 1996!), but that should at least give you a basic idea for the kind of things you'll need to do.



              If you choose to go to the FUSE route, here's libfuse, the reference implementation of the userspace side of the FUSE interface.



              Filesystem driver as a kernel module



              Basically, the initialization function of your filesystem driver module needs just to call a register_filesystem() function, and give it as a parameter a structure that includes a function pointer that identifies the function in your filesystem driver that will be used as the first step in identifying your filesystem type and mounting it. Nothing more happens at that stage.



              When a filesystem is being mounted, and either the filesystem type is specified to match your driver, or filesystem type auto-detection is being performed, the kernel's Virtual FileSystem (VFS for short) layer will call that function. It basically says "Here's a pointer to a kernel-level representation of a standard Linux block device. Take a look at it, see if it's something you can handle, and then tell me what you can do with it."



              At that point, your driver is supposed to read whatever it needs to verify it's the right driver for the filesystem, and then return a structure that includes pointers to further functions your driver can do with that particular filesystem. Or if the filesystem driver does not recognize the data on the disk, it is supposed to return an appropriate error result, and then VFS will either report a failure to userspace or - if filesystem type auto-detection is being performed - will ask another filesystem driver to try.



              The other drivers in the kernel will provide the standard block device interface, so the filesystem driver won't have to implement hardware support. Basically, the filesystem driver can read and write disk blocks using standard kernel-level functions with the device pointer given to it.



              The VFS layer expects the filesystem driver to make a number of standard functions available to the VFS layer; a few of these are mandatory in order for the VFS layer to do anything meaningful with the filesystem, others are optional and you can just return a NULL in place of a pointer to such an optional function.







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited yesterday

























              answered yesterday









              telcoMtelcoM

              20k12450




              20k12450








              • 1





                This is a pretty good answer though to fully answer the question as stated you'd also need to say a bit about the functionality the block device layer provides for the file system layer to build upon.

                – kasperd
                yesterday











              • I sort of alluded to that with the "here's a pointer to a standard block device" bit, but good point; I expanded on that.

                – telcoM
                yesterday











              • This answer, specifically the description of what happens in what order, is divine. Is there some sort of book/website I could read that has descriptions like that for all of "how linux works"?

                – Adam Barnes
                yesterday











              • You might be interested in Linux Kernel Internals or Linux Device Drivers, 3rd Edition. And of course, there's the option of reading the actual source code.

                – telcoM
                yesterday
















              • 1





                This is a pretty good answer though to fully answer the question as stated you'd also need to say a bit about the functionality the block device layer provides for the file system layer to build upon.

                – kasperd
                yesterday











              • I sort of alluded to that with the "here's a pointer to a standard block device" bit, but good point; I expanded on that.

                – telcoM
                yesterday











              • This answer, specifically the description of what happens in what order, is divine. Is there some sort of book/website I could read that has descriptions like that for all of "how linux works"?

                – Adam Barnes
                yesterday











              • You might be interested in Linux Kernel Internals or Linux Device Drivers, 3rd Edition. And of course, there's the option of reading the actual source code.

                – telcoM
                yesterday










              1




              1





              This is a pretty good answer though to fully answer the question as stated you'd also need to say a bit about the functionality the block device layer provides for the file system layer to build upon.

              – kasperd
              yesterday





              This is a pretty good answer though to fully answer the question as stated you'd also need to say a bit about the functionality the block device layer provides for the file system layer to build upon.

              – kasperd
              yesterday













              I sort of alluded to that with the "here's a pointer to a standard block device" bit, but good point; I expanded on that.

              – telcoM
              yesterday





              I sort of alluded to that with the "here's a pointer to a standard block device" bit, but good point; I expanded on that.

              – telcoM
              yesterday













              This answer, specifically the description of what happens in what order, is divine. Is there some sort of book/website I could read that has descriptions like that for all of "how linux works"?

              – Adam Barnes
              yesterday





              This answer, specifically the description of what happens in what order, is divine. Is there some sort of book/website I could read that has descriptions like that for all of "how linux works"?

              – Adam Barnes
              yesterday













              You might be interested in Linux Kernel Internals or Linux Device Drivers, 3rd Edition. And of course, there's the option of reading the actual source code.

              – telcoM
              yesterday







              You might be interested in Linux Kernel Internals or Linux Device Drivers, 3rd Edition. And of course, there's the option of reading the actual source code.

              – telcoM
              yesterday















              4














              Yes a kernel driver can manage a file-system .



              The best solution to mock up , prototype a file-system is to use FUSE . And after you can think about transform it into a kernel driver .



              Wikipedia =>
              https://en.wikipedia.org/wiki/Filesystem_in_Userspace



              Source => https://github.com/libfuse/libfuse



              a tutorial => https://developer.ibm.com/articles/l-fuse/






              share|improve this answer




























                4














                Yes a kernel driver can manage a file-system .



                The best solution to mock up , prototype a file-system is to use FUSE . And after you can think about transform it into a kernel driver .



                Wikipedia =>
                https://en.wikipedia.org/wiki/Filesystem_in_Userspace



                Source => https://github.com/libfuse/libfuse



                a tutorial => https://developer.ibm.com/articles/l-fuse/






                share|improve this answer


























                  4












                  4








                  4







                  Yes a kernel driver can manage a file-system .



                  The best solution to mock up , prototype a file-system is to use FUSE . And after you can think about transform it into a kernel driver .



                  Wikipedia =>
                  https://en.wikipedia.org/wiki/Filesystem_in_Userspace



                  Source => https://github.com/libfuse/libfuse



                  a tutorial => https://developer.ibm.com/articles/l-fuse/






                  share|improve this answer













                  Yes a kernel driver can manage a file-system .



                  The best solution to mock up , prototype a file-system is to use FUSE . And after you can think about transform it into a kernel driver .



                  Wikipedia =>
                  https://en.wikipedia.org/wiki/Filesystem_in_Userspace



                  Source => https://github.com/libfuse/libfuse



                  a tutorial => https://developer.ibm.com/articles/l-fuse/







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered yesterday









                  EchoMike444EchoMike444

                  1,0506




                  1,0506























                      0














                      Yes this would typically be done using a kernel driver that can either be loaded as a kernel module or compiled into the kernel.



                      You can check out similar filesystem drivers and how they work here.



                      These drivers likely use internal kernel functions to access storage devices as blocks of bytes but you could also use blockdevices as exposed by drivers in the block devices and character devices folders.






                      share|improve this answer








                      New contributor




                      Erik is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                      Check out our Code of Conduct.

























                        0














                        Yes this would typically be done using a kernel driver that can either be loaded as a kernel module or compiled into the kernel.



                        You can check out similar filesystem drivers and how they work here.



                        These drivers likely use internal kernel functions to access storage devices as blocks of bytes but you could also use blockdevices as exposed by drivers in the block devices and character devices folders.






                        share|improve this answer








                        New contributor




                        Erik is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                        Check out our Code of Conduct.























                          0












                          0








                          0







                          Yes this would typically be done using a kernel driver that can either be loaded as a kernel module or compiled into the kernel.



                          You can check out similar filesystem drivers and how they work here.



                          These drivers likely use internal kernel functions to access storage devices as blocks of bytes but you could also use blockdevices as exposed by drivers in the block devices and character devices folders.






                          share|improve this answer








                          New contributor




                          Erik is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                          Check out our Code of Conduct.










                          Yes this would typically be done using a kernel driver that can either be loaded as a kernel module or compiled into the kernel.



                          You can check out similar filesystem drivers and how they work here.



                          These drivers likely use internal kernel functions to access storage devices as blocks of bytes but you could also use blockdevices as exposed by drivers in the block devices and character devices folders.







                          share|improve this answer








                          New contributor




                          Erik is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                          Check out our Code of Conduct.









                          share|improve this answer



                          share|improve this answer






                          New contributor




                          Erik is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                          Check out our Code of Conduct.









                          answered yesterday









                          ErikErik

                          31




                          31




                          New contributor




                          Erik is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                          Check out our Code of Conduct.





                          New contributor





                          Erik is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                          Check out our Code of Conduct.






                          Erik is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                          Check out our Code of Conduct.























                              0














                              You can use fuse, to make a user-land file-system, or write a kernel module.
                              It is easier to do with fuse, as you have a choice of languages, and won't crash the kernel (and therefore the whole system).



                              Kernel modules can be faster, but the first rule of optimisation is: Don't do it until you have tested working code. The second is like it: Don't do it until you have evidence that it is too slow. And the third: Don't keep it unless you have evidence that it makes it faster/smaller.



                              And yes the kernel already has drivers for the hardware, you don't re-implement them.






                              share|improve this answer
























                              • There are major downsides to FUSE other than performance: it's hard to use it for your root filesystem. (Maybe possible with an initrd, but the FUSE binary couldn't be freed after booting because it would still be executing from the ramdisk.)

                                – Peter Cordes
                                yesterday






                              • 1





                                @PeterCordes It couldn't be freed, but that doesn't mean it can't be unlinked. If there's still a reference to it, it'll be kept in memory regardless of whether or not you left the initramfs and deleted the underlying binary.

                                – forest
                                19 hours ago











                              • @forest: right, therefore you can't unmount the initrd after pivot_root, because there are still busy inodes in the initramfs.

                                – Peter Cordes
                                19 hours ago













                              • A normal /init started from an initramfs will (I think) execve /init after pivot_root, to transfer control to the real root FS's /init. But a FUSE binary couldn't replace itself with execve if access to the root FS depended on the FUSE process responding to the kernel. Well maybe by priming the pagecache first, but that doesn't sound reliable.

                                – Peter Cordes
                                18 hours ago


















                              0














                              You can use fuse, to make a user-land file-system, or write a kernel module.
                              It is easier to do with fuse, as you have a choice of languages, and won't crash the kernel (and therefore the whole system).



                              Kernel modules can be faster, but the first rule of optimisation is: Don't do it until you have tested working code. The second is like it: Don't do it until you have evidence that it is too slow. And the third: Don't keep it unless you have evidence that it makes it faster/smaller.



                              And yes the kernel already has drivers for the hardware, you don't re-implement them.






                              share|improve this answer
























                              • There are major downsides to FUSE other than performance: it's hard to use it for your root filesystem. (Maybe possible with an initrd, but the FUSE binary couldn't be freed after booting because it would still be executing from the ramdisk.)

                                – Peter Cordes
                                yesterday






                              • 1





                                @PeterCordes It couldn't be freed, but that doesn't mean it can't be unlinked. If there's still a reference to it, it'll be kept in memory regardless of whether or not you left the initramfs and deleted the underlying binary.

                                – forest
                                19 hours ago











                              • @forest: right, therefore you can't unmount the initrd after pivot_root, because there are still busy inodes in the initramfs.

                                – Peter Cordes
                                19 hours ago













                              • A normal /init started from an initramfs will (I think) execve /init after pivot_root, to transfer control to the real root FS's /init. But a FUSE binary couldn't replace itself with execve if access to the root FS depended on the FUSE process responding to the kernel. Well maybe by priming the pagecache first, but that doesn't sound reliable.

                                – Peter Cordes
                                18 hours ago
















                              0












                              0








                              0







                              You can use fuse, to make a user-land file-system, or write a kernel module.
                              It is easier to do with fuse, as you have a choice of languages, and won't crash the kernel (and therefore the whole system).



                              Kernel modules can be faster, but the first rule of optimisation is: Don't do it until you have tested working code. The second is like it: Don't do it until you have evidence that it is too slow. And the third: Don't keep it unless you have evidence that it makes it faster/smaller.



                              And yes the kernel already has drivers for the hardware, you don't re-implement them.






                              share|improve this answer













                              You can use fuse, to make a user-land file-system, or write a kernel module.
                              It is easier to do with fuse, as you have a choice of languages, and won't crash the kernel (and therefore the whole system).



                              Kernel modules can be faster, but the first rule of optimisation is: Don't do it until you have tested working code. The second is like it: Don't do it until you have evidence that it is too slow. And the third: Don't keep it unless you have evidence that it makes it faster/smaller.



                              And yes the kernel already has drivers for the hardware, you don't re-implement them.







                              share|improve this answer












                              share|improve this answer



                              share|improve this answer










                              answered yesterday









                              ctrl-alt-delorctrl-alt-delor

                              12.1k42561




                              12.1k42561













                              • There are major downsides to FUSE other than performance: it's hard to use it for your root filesystem. (Maybe possible with an initrd, but the FUSE binary couldn't be freed after booting because it would still be executing from the ramdisk.)

                                – Peter Cordes
                                yesterday






                              • 1





                                @PeterCordes It couldn't be freed, but that doesn't mean it can't be unlinked. If there's still a reference to it, it'll be kept in memory regardless of whether or not you left the initramfs and deleted the underlying binary.

                                – forest
                                19 hours ago











                              • @forest: right, therefore you can't unmount the initrd after pivot_root, because there are still busy inodes in the initramfs.

                                – Peter Cordes
                                19 hours ago













                              • A normal /init started from an initramfs will (I think) execve /init after pivot_root, to transfer control to the real root FS's /init. But a FUSE binary couldn't replace itself with execve if access to the root FS depended on the FUSE process responding to the kernel. Well maybe by priming the pagecache first, but that doesn't sound reliable.

                                – Peter Cordes
                                18 hours ago





















                              • There are major downsides to FUSE other than performance: it's hard to use it for your root filesystem. (Maybe possible with an initrd, but the FUSE binary couldn't be freed after booting because it would still be executing from the ramdisk.)

                                – Peter Cordes
                                yesterday






                              • 1





                                @PeterCordes It couldn't be freed, but that doesn't mean it can't be unlinked. If there's still a reference to it, it'll be kept in memory regardless of whether or not you left the initramfs and deleted the underlying binary.

                                – forest
                                19 hours ago











                              • @forest: right, therefore you can't unmount the initrd after pivot_root, because there are still busy inodes in the initramfs.

                                – Peter Cordes
                                19 hours ago













                              • A normal /init started from an initramfs will (I think) execve /init after pivot_root, to transfer control to the real root FS's /init. But a FUSE binary couldn't replace itself with execve if access to the root FS depended on the FUSE process responding to the kernel. Well maybe by priming the pagecache first, but that doesn't sound reliable.

                                – Peter Cordes
                                18 hours ago



















                              There are major downsides to FUSE other than performance: it's hard to use it for your root filesystem. (Maybe possible with an initrd, but the FUSE binary couldn't be freed after booting because it would still be executing from the ramdisk.)

                              – Peter Cordes
                              yesterday





                              There are major downsides to FUSE other than performance: it's hard to use it for your root filesystem. (Maybe possible with an initrd, but the FUSE binary couldn't be freed after booting because it would still be executing from the ramdisk.)

                              – Peter Cordes
                              yesterday




                              1




                              1





                              @PeterCordes It couldn't be freed, but that doesn't mean it can't be unlinked. If there's still a reference to it, it'll be kept in memory regardless of whether or not you left the initramfs and deleted the underlying binary.

                              – forest
                              19 hours ago





                              @PeterCordes It couldn't be freed, but that doesn't mean it can't be unlinked. If there's still a reference to it, it'll be kept in memory regardless of whether or not you left the initramfs and deleted the underlying binary.

                              – forest
                              19 hours ago













                              @forest: right, therefore you can't unmount the initrd after pivot_root, because there are still busy inodes in the initramfs.

                              – Peter Cordes
                              19 hours ago







                              @forest: right, therefore you can't unmount the initrd after pivot_root, because there are still busy inodes in the initramfs.

                              – Peter Cordes
                              19 hours ago















                              A normal /init started from an initramfs will (I think) execve /init after pivot_root, to transfer control to the real root FS's /init. But a FUSE binary couldn't replace itself with execve if access to the root FS depended on the FUSE process responding to the kernel. Well maybe by priming the pagecache first, but that doesn't sound reliable.

                              – Peter Cordes
                              18 hours ago







                              A normal /init started from an initramfs will (I think) execve /init after pivot_root, to transfer control to the real root FS's /init. But a FUSE binary couldn't replace itself with execve if access to the root FS depended on the FUSE process responding to the kernel. Well maybe by priming the pagecache first, but that doesn't sound reliable.

                              – Peter Cordes
                              18 hours ago





                              Popular posts from this blog

                              Færeyskur hestur Heimild | Tengill | Tilvísanir | LeiðsagnarvalRossið - síða um færeyska hrossið á færeyskuGott ár hjá færeyska hestinum

                              He _____ here since 1970 . Answer needed [closed]What does “since he was so high” mean?Meaning of “catch birds for”?How do I ensure “since” takes the meaning I want?“Who cares here” meaningWhat does “right round toward” mean?the time tense (had now been detected)What does the phrase “ring around the roses” mean here?Correct usage of “visited upon”Meaning of “foiled rail sabotage bid”It was the third time I had gone to Rome or It is the third time I had been to Rome

                              Slayer Innehåll Historia | Stil, komposition och lyrik | Bandets betydelse och framgångar | Sidoprojekt och samarbeten | Kontroverser | Medlemmar | Utmärkelser och nomineringar | Turnéer och festivaler | Diskografi | Referenser | Externa länkar | Navigeringsmenywww.slayer.net”Metal Massacre vol. 1””Metal Massacre vol. 3””Metal Massacre Volume III””Show No Mercy””Haunting the Chapel””Live Undead””Hell Awaits””Reign in Blood””Reign in Blood””Gold & Platinum – Reign in Blood””Golden Gods Awards Winners”originalet”Kerrang! Hall Of Fame””Slayer Looks Back On 37-Year Career In New Video Series: Part Two””South of Heaven””Gold & Platinum – South of Heaven””Seasons in the Abyss””Gold & Platinum - Seasons in the Abyss””Divine Intervention””Divine Intervention - Release group by Slayer””Gold & Platinum - Divine Intervention””Live Intrusion””Undisputed Attitude””Abolish Government/Superficial Love””Release “Slatanic Slaughter: A Tribute to Slayer” by Various Artists””Diabolus in Musica””Soundtrack to the Apocalypse””God Hates Us All””Systematic - Relationships””War at the Warfield””Gold & Platinum - War at the Warfield””Soundtrack to the Apocalypse””Gold & Platinum - Still Reigning””Metallica, Slayer, Iron Mauden Among Winners At Metal Hammer Awards””Eternal Pyre””Eternal Pyre - Slayer release group””Eternal Pyre””Metal Storm Awards 2006””Kerrang! Hall Of Fame””Slayer Wins 'Best Metal' Grammy Award””Slayer Guitarist Jeff Hanneman Dies””Bullet-For My Valentine booed at Metal Hammer Golden Gods Awards””Unholy Aliance””The End Of Slayer?””Slayer: We Could Thrash Out Two More Albums If We're Fast Enough...””'The Unholy Alliance: Chapter III' UK Dates Added”originalet”Megadeth And Slayer To Co-Headline 'Canadian Carnage' Trek”originalet”World Painted Blood””Release “World Painted Blood” by Slayer””Metallica Heading To Cinemas””Slayer, Megadeth To Join Forces For 'European Carnage' Tour - Dec. 18, 2010”originalet”Slayer's Hanneman Contracts Acute Infection; Band To Bring In Guest Guitarist””Cannibal Corpse's Pat O'Brien Will Step In As Slayer's Guest Guitarist”originalet”Slayer’s Jeff Hanneman Dead at 49””Dave Lombardo Says He Made Only $67,000 In 2011 While Touring With Slayer””Slayer: We Do Not Agree With Dave Lombardo's Substance Or Timeline Of Events””Slayer Welcomes Drummer Paul Bostaph Back To The Fold””Slayer Hope to Unveil Never-Before-Heard Jeff Hanneman Material on Next Album””Slayer Debut New Song 'Implode' During Surprise Golden Gods Appearance””Release group Repentless by Slayer””Repentless - Slayer - Credits””Slayer””Metal Storm Awards 2015””Slayer - to release comic book "Repentless #1"””Slayer To Release 'Repentless' 6.66" Vinyl Box Set””BREAKING NEWS: Slayer Announce Farewell Tour””Slayer Recruit Lamb of God, Anthrax, Behemoth + Testament for Final Tour””Slayer lägger ner efter 37 år””Slayer Announces Second North American Leg Of 'Final' Tour””Final World Tour””Slayer Announces Final European Tour With Lamb of God, Anthrax And Obituary””Slayer To Tour Europe With Lamb of God, Anthrax And Obituary””Slayer To Play 'Last French Show Ever' At Next Year's Hellfst””Slayer's Final World Tour Will Extend Into 2019””Death Angel's Rob Cavestany On Slayer's 'Farewell' Tour: 'Some Of Us Could See This Coming'””Testament Has No Plans To Retire Anytime Soon, Says Chuck Billy””Anthrax's Scott Ian On Slayer's 'Farewell' Tour Plans: 'I Was Surprised And I Wasn't Surprised'””Slayer””Slayer's Morbid Schlock””Review/Rock; For Slayer, the Mania Is the Message””Slayer - Biography””Slayer - Reign In Blood”originalet”Dave Lombardo””An exclusive oral history of Slayer”originalet”Exclusive! Interview With Slayer Guitarist Jeff Hanneman”originalet”Thinking Out Loud: Slayer's Kerry King on hair metal, Satan and being polite””Slayer Lyrics””Slayer - Biography””Most influential artists for extreme metal music””Slayer - Reign in Blood””Slayer guitarist Jeff Hanneman dies aged 49””Slatanic Slaughter: A Tribute to Slayer””Gateway to Hell: A Tribute to Slayer””Covered In Blood””Slayer: The Origins of Thrash in San Francisco, CA.””Why They Rule - #6 Slayer”originalet”Guitar World's 100 Greatest Heavy Metal Guitarists Of All Time”originalet”The fans have spoken: Slayer comes out on top in readers' polls”originalet”Tribute to Jeff Hanneman (1964-2013)””Lamb Of God Frontman: We Sound Like A Slayer Rip-Off””BEHEMOTH Frontman Pays Tribute To SLAYER's JEFF HANNEMAN””Slayer, Hatebreed Doing Double Duty On This Year's Ozzfest””System of a Down””Lacuna Coil’s Andrea Ferro Talks Influences, Skateboarding, Band Origins + More””Slayer - Reign in Blood””Into The Lungs of Hell””Slayer rules - en utställning om fans””Slayer and Their Fans Slashed Through a No-Holds-Barred Night at Gas Monkey””Home””Slayer””Gold & Platinum - The Big 4 Live from Sofia, Bulgaria””Exclusive! Interview With Slayer Guitarist Kerry King””2008-02-23: Wiltern, Los Angeles, CA, USA””Slayer's Kerry King To Perform With Megadeth Tonight! - Oct. 21, 2010”originalet”Dave Lombardo - Biography”Slayer Case DismissedArkiveradUltimate Classic Rock: Slayer guitarist Jeff Hanneman dead at 49.”Slayer: "We could never do any thing like Some Kind Of Monster..."””Cannibal Corpse'S Pat O'Brien Will Step In As Slayer'S Guest Guitarist | The Official Slayer Site”originalet”Slayer Wins 'Best Metal' Grammy Award””Slayer Guitarist Jeff Hanneman Dies””Kerrang! Awards 2006 Blog: Kerrang! Hall Of Fame””Kerrang! Awards 2013: Kerrang! Legend”originalet”Metallica, Slayer, Iron Maien Among Winners At Metal Hammer Awards””Metal Hammer Golden Gods Awards””Bullet For My Valentine Booed At Metal Hammer Golden Gods Awards””Metal Storm Awards 2006””Metal Storm Awards 2015””Slayer's Concert History””Slayer - Relationships””Slayer - Releases”Slayers officiella webbplatsSlayer på MusicBrainzOfficiell webbplatsSlayerSlayerr1373445760000 0001 1540 47353068615-5086262726cb13906545x(data)6033143kn20030215029