A NAS Integrated File System for On-site IoT Data
Storage
Yuki Okamoto1 Kenichi Arai2 Toru Kobayashi2 Takuya Fujihashi1 Takashi Watanabe1 Shunsuke Saruwatari1
1

Graduate School of Information Science and Technology, Osaka University, Japan
2
Graduate School of Engineering, Nagasaki University, Japan

Abstract—In the case of IoT data acquisition, long-term storageof large amounts of sensor data is a signiﬁcant challenge. When acloud service is used, ﬁxed costs such as a communication line for
uploading and a monthly fee are unavoidable. In addition, the useof large-capacity storage servers incurs high initial installation
costs. In this paper, we propose a Network Attached Storage(NAS) integrated ﬁle system called the “Sensor Data File System(SDFS)”, which has advantages of being on-site, low-cost, andhighly scalable. We developed the SDFS using FUSE, which
is an interface for implementing ﬁle systems in user-space. In
this work, we compared SDFS with existing integrated storage
modalities such as aufs and unionfs-fuse. The results indicate that
SDFS achieves an equivalent throughput compared with existingﬁle systems in terms of read/write performance. SDFS not only
allows multiple NAS to be treated as a single ﬁle system but also
has functions that facilitate the ease of the addition of storage.
Index Terms—IoT, virtual ﬁle system, storage, union mount

I. I NTRODUCTION
With the advent of computing devices such as Arduino andRaspberry Pi as well as communication technologies such as
BLE (Bluetooth Low Energy) and LPWA (Low Power, WideArea), the Internet of Things (IoT) is developing rapidly. IoT
applications are being introduced in various ﬁelds, including
industrial manufacturing, agriculture, architecture, civil engineering, energy, logistics, commerce, and education. The
success of IoT systems in these diverse applications depends
on the ability to build and operate IoT services in real-time. For
example, Asahi Iron Works in Aichi, Japan, has built a factoryline monitoring system by combining electrical components
purchased in Akihabara. In the process, they succeeded in
reducing investment by 400 million yen and labor costs by
100 million yen [1].
In the case of IoT data acquisition, long-term storage oflarge amounts of sensor data is a signiﬁcant challenge. To address this problem, a low-cost, highly scalable storage system
is desirable. When a cloud service is used for the storage ofdata, ﬁxed costs such as a communication line for uploading
and a monthly fee are unavoidable. In addition, large-capacity
storage servers have high initial installation costs. Although
an on-site IoT system is gradually extended based on theminimum requirements, the use of existing storage systems is
not practical. The challenges associated with existing storage
systems are discussed in Section II.
In this paper, we propose on a Network Attached Storage(NAS) integrated ﬁle system called the “Sensor Data File
System (SDFS)”, which is on-site, low-cost, and highly scalable. SDFS effectively stores and manages large amounts ofsensor data. In this work, we compared SDFS with the existing
integrated storages such as aufs and unionfs-fuse. The results
indicated that SDFS achieves the equivalent throughput ofexisting ﬁle systems in terms of read/write performance. In

SDFS, multiple NAS can be handled as one ﬁle system andusers can easily add new NAS.
The remainder of this paper is organized as follows. In
section 2, we discuss the issues associated with the sensor data
storage. Section 3 describes the overview and implementationof the proposed ﬁle system, SDFS. In section 4, we evaluate
the performance of SDFS and existing ﬁle systems. Section 5
introduces related work, and Section 6 summarizes the mainﬁndings of this paper.
II. I SSUES ASSOCIATED WITH THE SENSOR DATA STORAGE
With the advent of hardware platforms and communication
standards, it has become easier to install sensors and tocollect data. For example, we are currently developing a
Gunkanjima monitoring system to facilitate building structure
analysis based on the acquisition of video and acceleration dataof building structures that are collapsing on the uninhabitedisland [2]. Since 2016, approximately 8 TB of sensor data has
already been collected. Storage is a signiﬁcant challenge whencollecting sensor data that is growing over time.
Typically, storage requirements are as follows:
1) Easy expansion and management with low cost2) Storing data in time-series
3) Existing software can be used
First, easy expansion and management with low cost areimportant aspects due to the critical importance of the sensor
data. Sensor data continues to store with the initiation ofdata acquisition. In addition, given the recent advancements
in data analysis technology, it is desirable to store as muchprevious data as possible. For example, as mentioned earlier,the Gunkanjima monitoring system has stored 8 TB of data,with an increase of approximately 10 GB per day. The current
monitoring system in Gunkanjima stores sensor data on multiple NAS. When the capacity of the NAS is insufﬁcient, it must
be switched by manually rewriting the program. In addition,
as of this year, we have initiated research on the extraction of
the collapse location of Gunkanjima by using acquired image
data. As the types and amounts of stored sensor data increase,new demands arise.
Second, considering the characteristics of the sensor data,i.e., the sensor data is associated with time, storing datain time-series is a key requirement. During the extractionof sensor data from a large amount of data for a period,
referring to multiple storages individually is inefﬁcient for datautilization. Ideally, close time-series data should be stored in
the same storage.
The third requirement is important because existing standard
ﬁle management software is used for IoT systems such as the
Gunkanjima monitering system. Some ﬁle operation instructions such as ls, cp, mv, rm, and rsync can still be used fordata management.

Cloud storage
Microsoft Azure Files
DropboxAmazon S3
IBM Cloud Object Storage (Cold Vault)

Monthly usage fee [$]480.0
285.05200.0
72.0

As a means of storing sensor data, it is conceivable touse a cloud-based storage service. For example, cloud storage
such as Amazon S3 is advantageous with respect to using
the acquired sensor data in multiple locations. However, it
is expensive to store a large amount of data. Table I shows
the monthly cost of usage for major cloud storage services.
The table provides a summary of the cost associated with the
upload of 300 GB of data per month for 8 TB of storage.
The usage cost may be higher than the stipulated amountbecause a transfer fee for processes such as downloading istypically added. In addition, data stores over time and assuch, storage charges must continue to be paid as ﬁxed costs.
From the perspective of creating new services based on sensor
data, systems that require a high level of ﬁnancial resources
for continuous operation should be avoided. A large-capacity
storage server is one solution to the problem of the storeof large amounts of sensor data. However, storage servers
are generally expensive. In addition, there are inappropriateelements associated with the increase of sensor data, such as
the upper limit of the amount of data that can be stored.
III. P ROPOSAL : S ENSOR DATA F ILE S YSTEM
A. Overview of SDFS
Based on the discussion in Section II, we consider buildinga Virtual File System (VFS) that can be considered as a single
storage system by integrating multiple NAS. Fig.1 shows thedetails of access to a ﬁle when multiple NAS are integrated.
As shown in Fig.1, to manipulate ﬁle.dat, the VFS must accesseach NAS to conﬁrm the existence of the ﬁle. When accessing
a ﬁle, it is not possible to determine which NAS stores theﬁle, therefore, it is necessary to check the existence of theﬁle/directory for each NAS. As the amount of processed data
increases, the VFS performs more checks for the existenceof ﬁles. Therefore, when integrating multiple NAS, the main
problem is an increase in the overhead of the VFS.

PQWQDVILOHGDWPQWYIVILOHGDW Virtual

User

File
Systemnas01

PQWQDVILOHGDW

nas02
PQWQDVILOHGDW

nas03
ILOHGDW

Fig. 1. Access to ﬁles in multiple NAS integrated VFS

Based on this discussion, we propose the “Sensor Data File
System (SDFS)”, a user-space ﬁle system for IoT data thatsatisﬁes the three requirements described in Section 2. SDFS
has the following ﬁve features for the efﬁcient managementof time-series IoT data.
1) Multiple NAS can be handled as one ﬁle system.
2) Users can add a new NAS simply by rewriting the
conﬁguration ﬁle.
3) When the remaining capacity of the NAS decreases, it
is automatically saved on another NAS.
4) Files with similar dates are saved on the same NAS.
5) Users can perform normal operations on one of theintegrated NAS.
File management software: ls, cp, mv, rsync, etc.

SDFS

TABLE IE XAMPLE OF MONTHLY USAGE AMOUNTS FOR CLOUD STORAGE

NAS1FUSE API

Configuration Filegetattr, open, read, etc.

/etc/sdfs.conf

SDFS APIPath conversion
mechanism

NAS2

NAS3

NAS4

Fig. 2. Overview of SDFS

In SDFS, a format for storing sensor data is standardized as
an SDFS path. Speciﬁcally, when SDFS is mounted on /sdfs,
it is standardized in the following format.
/sdfs/[sensor type]/[year]/[month]/[day]/[name]For example, if the acceleration sensor data on September
10th, 2019 is acc.csv, the SDFS path is following.
/sdfs/acc/2019/09/10/acc.csv

Figure 2 shows an overview of SDFS when four NAS are
integrated. In SDFS, existing ﬁle management software suchas cp, mv, and rsync can be used. They are used to manage
the SDFS path. SDFS is implemented on Linux using FUSE[6], [7]. FUSE is an interface for implementing ﬁle systems
in user-space. Many ﬁle systems have been developed using
FUSE for applications such as veriﬁcation prototypes (e.g.,
GlusterFS [3], zfs-fuse [4], SafeFS [5]). In the implementationof a ﬁle system using FUSE, unique functions can be realizedby overriding the hook function corresponding to the systemcall related to each ﬁle operation. When a ﬁle management
software performs an operation on a ﬁle or directory in
SDFS, the SDFS API is called via the FUSE API. The
SDFS API processes requests for ﬁles and directories received
from applications in cooperation with the path conversion
mechanism. This mechanism converts between SDFS paths
and actual paths. It provides the actual path to the NAS to
the SDFS API according to the operation target path, thecontent of the conﬁguration ﬁle, the ﬁles held by the NAS,and the remaining disk capacity of the NAS. Users edit the
conﬁguration ﬁle to add a new NAS or select a NAS to store
data.
B. Path conversion mechanism: Reading conﬁguration ﬁleReading the conﬁguration ﬁle of the path conversion mechanism is implemented as a thread and is executed periodi-

cally. The thread acquires the NAS mount point information
described in the conﬁguration ﬁle and checks the remaining
capacity of each mounted NAS.
The conﬁguration ﬁle is given as a pair of the path pattern ofthe directory on SDFS, and the mount point of the corresponding NAS. The path pattern is described as an absolute pathwith the mount point as the root. Users can utilize wildcards.
SDFS is mounted on /sdfs, and three NAS are mounted as/mnt/nas01, /mnt/nas02, and /mnt/nas03. At this point, if the
conﬁguration ﬁle /etc/sdfs.conf contains the following, the ﬁles
are saved in the order they were written until the capacity is
exceeded.
/ /mnt/nas01/ /mnt/nas02/ /mnt/nas03
In SDFS, users can select the NAS to save according to
the type, year, and month of the acquired sensor data. If thesetting ﬁle is described as follows, sensor data from January
to September 2017 will be saved in /mnt/nas01. In addition,
sensor data from October to December 2017 and 2018 will besaved to /mnt/nas02, and sensor data for 2019 will be saved
to /mnt/nas03.
/*/2017 /mnt/nas01/*/2017/10 /mnt/nas02/*/2017/11 /mnt/nas02/*/2017/12 /mnt/nas02/*/2018 /mnt/nas02/*/2019 /mnt/nas03
C. Path conversion mechanism: Checking existence of the ﬁleReading and writing requirements to satisfy the feature of
SDFS are realized by path rewriting of the path conversion
mechanism. To check for the existence of ﬁles that need tobe read and written, the actual path of each NAS must be
speciﬁed and accessed over the network. In Section III-A, we
discussed that the process of integrating multiple NAS in thevirtual ﬁle system may lead to overhead.
A possible solution is to implement a negative cacheto the ﬁle existence checking function of SDFS. In thisprocess, information is cached to indicate that the ﬁledoes not exist. For example, if it is cached that the directory “/mov b30SS/2019/11” does not exist in the NAS,
it can be returned that there is no ﬁle for any such
request under this directory. In this case, ﬁles such as“/mov b30SS/2019/11/14/building 001.mov” hit the negative
cache in the upper hierarchy, therefore, the increase in overhead can be limited. If the ﬁle information on the NAS
can be returned in the cache without accessing the network
for reference when checking for the existence of a ﬁle, theoverhead can be reduced.
Algorithm 1 shows the ﬁle existence checking function in
the path conversion mechanism of SDFS, and Tab.II shows
the variables and functions used in Algorithm 1.
D. SDFS API: Reading
Reading in SDFS can be performed as if the ﬁles distributedin multiple NAS are in one directory. For example, even if
NAS1, NAS2, and NAS3 have different ﬁles in the directoryon September 10, 2019, SDFS can access them as if they exist
in three directories.

Algorithm 1 File existence checking function
Require: p
Ensure: return true if p exists, return false if p not exists
1: A ←split(p, “/”)
2: s = “”
3: for i = 1 to size(A) do
4:s ←strcat(s, A[i])5:if checkNCache(s) == true then6:
return false
7:
end if
8: end for
9: s = “”
10: for i = 1 to size(A) do
11:s ←strcat(s, A[i])12:
if lstat(s) == 1 then13:
addNCache(s)14:
return false
15:
end if
16: end for
17: return true
TABLE IIalgorithim VARIABLES AND FUNCTIONS USED IN 1
Variable, FunctionpA
split(s1 , s2 )strcat(s1 , s2 )checkNCache(s)lstat(s)addNCache(s)Explanation
The path to check for existence.
A list that stores paths decomposed by hierarchy.
A function that returns a string s1 as an arrayseparated by the string s2 .
A function that returns a string that combines
s1 and s2 .
A function that checks whether s exists in thenegative cache.
A function to check the status of ﬁle s.
Returns 0 if it exists, 1 otherwise.
A function to register the string s in the negative
cache.

Access to the ﬁle is read in the order of the longest preﬁxthat matches the conﬁguration ﬁle. SDFS reads from the
NAS that has the longest preﬁx match with the path patterndescribed in the conﬁguration ﬁle. At this time, the existenceof the ﬁle is checked, and reading is performed only when theﬁle exists. If there are multiple NAS with preﬁx matching of
the same length, the existence of the ﬁles is checked in theorder described in the conﬁguration ﬁle. Even if the same ﬁlewith the same path exists in different NAS, only the ﬁle foundthe earliest using the aforementioned method is read.
E. SDFS API: Writing
The procedure for writing to SDFS consists of three stages.
The ﬁrst stage is the conﬁrmation of the existence of the ﬁle tobe written. The existence of the target ﬁle is conﬁrmed using
the same procedure as that used for reading. If the ﬁle to be
written exists in SDFS, the associated NAS is selected as thewrite destination and it is overwritten. Otherwise, we proceed
to the second stage. If a ﬁle with the same name exists inthe same path on multiple NAS, the ﬁle on the NAS with thehighest order listed in the conﬁguration ﬁle is overwritten.
In the second stage, matching of the path pattern in the
conﬁguration ﬁle is performed. The path of the ﬁle to be
written matches the path pattern described in the conﬁgurationﬁle and is written to the remaining NAS with a large capacity.
When the remaining capacity of the NAS matched with thepath pattern is insufﬁcient, we proceed to the third stage. If
there are multiple matching path patterns, the path pattern withthe longest preﬁx match is given priority. If there are multiple

IV. E VALUATION
A. Evaluation environment
To conﬁrm the usefulness of SDFS, we evaluated thesynchronization performance and read/write throughput performance. In the evaluation, the following three ﬁle systems
are compared.
1) SDFS
The ﬁle system proposed in this paper. This ﬁle system
efﬁciently manages a large amount of sensor data. It is
assumed that sensor data is managed by multiple NAS.
2) unionfs-fuse [16]A FUSE-based implementation of UnionFS [10], [14],[15] that can transparently overlap multiple directories.
3) aufs [11]A ﬁle system developed to improve the reliability andperformance of UnionFS.
There are Samba [12] and Network File System (NFS)
as a sharing method of NAS over the network. Both areprotocols that enable remote mounting via a network for
locally connected storage. The NAS used for the evaluation
was constructed on RAID 1 with two 4TB HDD in Synology
DS218j.
B. Comparison with existing ﬁlesystem
We compare SDFS with existing ﬁlesystem using the following practical evaluation criteria.
1) When the number of NAS is increased, performancedoes not deteriorate.
2) The ﬁle system supports Samba.
3) There is no need to rebuild the kernel. It is importantfor ease of introduction.
4) NAS can be added without rebuilding the ﬁle system.
If the ﬁle system is stopped every time a new NAS
is added, sensor data that continues to increase every
minute and every second cannot be handled.
5) Users can select which NAS to write according to sensor
data type and date.
6) Write according to the remaining storage capacity.
Table III shows the comparison results based on the above
evaluation criteria.
TABLE IIIC OMPARISON OF SDFS AND EXISTING FILESYSTEM
SDFS
1)
2)
3)
4)
5)
6)

〇
〇
〇
〇
〇
〇

unionfs
-fuse
〇
〇
〇
×

×

aufs
〇
×
×
×

×

Aufs does not support storage shared by Samba. Therefore,
we shared the storage by NFS for the performance evaluationof aufs. SDFS, unionfs-fuse, and aufs ﬁle systems all exhibited
almost no performance degradation even when the numberof NAS to be integrated is increased. SDFS and unionfsfuse are FUSE-based ﬁle systems, rebuilding the kernel is
not necessary. However, kernel modules are provided for aufs,
and it is necessary to rebuild the kernel to use them. SDFS
allows the user to add a new NAS simply by rewriting the
conﬁguration ﬁle, but unionfs-fuse and aufs require a ﬁlesystem rebuild. In SDFS, users can select the NAS to write
according to the type/date of sensor data and the remaining
storage capacity. Although unionfs-fuse and aufs can select the
NAS to write according to the directory s name, the detailed
speciﬁcation as described in section III-B is not possible.
C. Rsync performance
We investigated the performance of rsync, which is aLinux ﬁle management software that synchronizes ﬁles anddirectories. When a large amount of data is stored and usedby sensors, rsync is used for back up. Experiments were
performed while changing the number of NAS units to be
integrated from 1 to 4 NAS units. We synchronized 10,000
new ﬁles with a ﬁle size of 256 B using rsync. Fig.3 showsthe experimental results obtained when the NAS is sharedwith Samba. The vertical axis represents the time when rsync
is completed, and the horizontal axis represents the numberof integrated NAS. Fig.3 shows that SDFS has better rsync
performance compared to unionfs-fuse. However, without thenegative cache function, SDFS’s performance is signiﬁcantly
reduced as the number of NAS increases. Rsync needs toobtain information about a ﬁle at various times, including
whether the ﬁle exists, whether the directory exists, or whether
the ﬁle needs to be updated. Therefore, when sharing a NASwith Samba, whether or not a negative cache exists greatly
affects the performance of rsync.
Fig.4 shows the experimental results obtained when sharing
the NAS with NFS. For NFS sharing, aufs has the best
rsync performance. SDFS and unionfs-fuse exhibit almost no
difference in performance, unlike sharing with Samba.
400

SDFS
unionfs-fuse
SDFS(w/o NC)

300

Total time (s)preﬁx patterns with the same length, the NAS written at the
top of the conﬁguration ﬁle takes precedence.
In the third stage, the remaining capacity is sufﬁcient andthe NAS listed at the top of the conﬁguration ﬁle is selected.
Saving in the order of the setting ﬁles allows sensor data witha similar date and time to be saved in the same NAS, and thetime-series to be maintained as much as possible.

200
100
0

1

2

3

Number of NAS

4

Fig. 3. Rsync performance (Samba)

D. Read/Write performance
We measured read/write throughput. The average write
performance was measured by writing the ﬁle 10 times andchanging the read ﬁle size from 1 B to 1GB in 10 times
increments. The write throughput is shown in Fig.5 whenFig.5-8 shows that SDFS achieves almost the same read/write
throughput as existing methods.

80

Total time (s)

40

SDFS
unionfs-fuse
SDFS(w/o NC)
aufs

20
0

1

2

3

4

Number of NAS

Read throughput (Mbps)

102

60

101

100

Fig. 4. Rsync performance (NFS)

NAS
SDFS
unionfs-fuse
100 101 102 103 104 105 106 107 108 109

File size (B)mounted with Samba and Fig.6 when mounted with NFS. The
vertical axis is the throughput (Mbps), and the horizontal axis
is the ﬁle size (B) when writing.

Fig. 7. Read throughput performance (Samba)

Write throughput (Mbps)

101

101

100

Read throughput (Mbps)

102
102

NAS
SDFS
unionfs-fuse
100

101

102

103

104

105

File size (B)

106

107

108

109

100

NAS
SDFS
unionfs-fuse
aufs
100 101 102 103 104 105 106 107 108 109

File size (B)Fig. 8. Read throughput performance (NFS)

Fig. 5. Write throughput performance (Samba)

Write throughput (Mbps)

102

101

100

NAS
SDFS
unionfs-fuse
aufs
100 101 102 103 104 105 106 107 108 109

File size (B)Fig. 6. Write throughput performance (NFS)

The read performance experiment is the same as the write
performance. The read throughput is shown in Fig.7 when
mounted with Samba and Fig.8 when mounted with NFS.

E. Negative cache lifetime
In the previous evaluation, the lifetime of the negative
cache in the path conversion mechanism was set to 60 s.
We examined the effect of negative cache survival on SDFS
performance. In this process, four NAS are shared with Samba
and the time for completion of rsync is measured whilechanging the SDFS negative cache lifetime. We synchronized
10,000 ﬁles with a ﬁle size of 256 B using rsync.
Fig.9 shows the experimental results. The vertical axis
represents the time for the completion of rsync, and thehorizontal axis represents the lifetime of the negative cache.
The negative cache worked effectively except when the cache
lifetime was 1 s. When the survival time was more than 10 s,
the performance of rsync was almost unchanged.
F. Reading interval of conﬁguration ﬁleIn the evaluation thus far, the setting ﬁle reading interval in
the path conversion mechanism was set to 60 s. The effect of
the setting ﬁle reading interval on the performance of SDFS is
veriﬁed. We measured the throughput of writing and readingwhen four NAS were shared by Samba and the setting ﬁlereading interval was changed in increments of 10 from 10−4 to102
Read throughput (Mbps)

600

Total time (s)

500
400
300
200
100
0

5

10

15

20

Negative cache life time (s)

101

100

10−4

10−3

10−2

10−1

1

101

Read interval of configuration file (s)Fig. 9. Rsync performance (Samba)

Fig. 11. Read throughput performance (Samba)

10 s. The average throughput was calculated when a ﬁle witha size of 10 kB was written and read 10 times. We calculated
the average throughput when reading and writing a ﬁle witha size of 10 kB 10 times.
Fig.10 shows the write throughput results and Fig.11 shows
the read throughput results when the read interval is changed.
The vertical axis is the throughput (Mbps), and the horizontal
axis is the reading interval of the conﬁguration ﬁle (s). If
the conﬁguration ﬁle read interval is 1 s or longer, read/write
throughput performance is not affected.

SDFS proposed in this paper is considered a kind of Union
Mount because it can overlap directories. SDFS is a ﬁle system
for sensor data that has an advantage when large amounts of
IoT data.

Write throughput (Mbps)

102

VI. C ONCLUSION
In this paper, we discussed the issues associated with thesensor data storage, and proposed SDFS, a multiple NAS
integrated ﬁle system, which has advantages of being on-site,
low-cost, and highly scalable. SDFS not only allows multiple
NAS to be treated as a single ﬁle system but also has featuresthat facilitate the ease of management of sensor data, and the
addition of storage. We conﬁrmed the practicality of SDFS
with several evaluation procedures.
R EFERENCES

101

100

10−4

10−3

10−2

10−1

1

101

Read interval of configuration file (s)Fig. 10. Write throughput performance (Samba)

V. R ELATED RESEARCH
Union mount [8] is a technology that transparently superimposes multiple directories such that it appears to containcombined content. An example of using Union Mount is alive Linux distribution that boots from optical media suchas CDs and DVDs. In such distributions, writing to optical
media is stored in memory. By unifying optical media andmemory transparently using Union Mount, it is possible towrite onto optical media in a pseudo manner. Typical ﬁlesystems that use this technology include UnionFS [10], aufs[11], and OverlayFS [13]. There is a demand for ﬁle systems
that can be stacked, and they have been eagerly developed [9].
Aufs is a ﬁle system derived from UnionFS and is used bymany services for stability and performance improvement. The[1] “IoT success in medium-sized manufacturing ﬁrm.” https://news.aperza.
jp/ July 2017.
[2] “Gunkanjima monitering project.” https://www-int.ist.osaka-u.ac.jp/
battleship/.
[3] “GlusterFS - scalable network ﬁlesystem.” https://www.gluster.org/.
[4] “zfs-fuse.” https://github.com/pscedu/zfs-fuse.
[5] Pontes, Rogério and Burihabwa, Dorian and Maia, Francisco and Paulo,João and Schiavoni, Valerio and Felber, Pascal and Mercier, Hugues andOliveira, Rui. “SafeFS: A Modular Architecture for Secure User-space
File Systems: One FUSE to Rule Them All.” Proceedings of the 10th
ACM International Systems and Storage Conference. SYSTOR ’17.
[6] Bharath Kumar Reddy Vangoor and Vasily Tarasov and Erez Zadok.
“To FUSE or Not to FUSE: Performance of User-Space File Systems.”
15th USENIX Conference on File and Storage Technologies (FAST 17).
2017. feb.
[7] M.Szeredi, “Filesystem in Userspace.” http://fuse.sourceforce.net. 2005.
[8] “Union mounts -a.k.a., writable overlays” http://valerieaurora.org/union/.
[9] Erez Zadok, Rakesh Iyer, Nikolai Joukov and Gopalan Sivathanu and
C. P. Wright “On Incremental File System Development.” ACM Transactions on Storage. May 2006. 1553-3077. 161–196.
[10] C. P. Wright and Erez Zadok. “Kernel Korner: Unionfs: Bringing
Filesystems Together.” Linux J. December 2004.
[11] “aufs.” http://aufs.sourceforge.net/aufs.html.
[12] “Samba.” https://www.samba.org/.
[13] “overlayfs.” https://github.com/torvalds/linux/tree/master/fs/overlayfs.
[14] C. P. Wright and M. N. Zubair. “Versatility and unix semantics innamespace uniﬁcatio.” ACM Transactions on Storage (TOS). 2006.
[15] J. S. Pendry and M. K. McKusick. “VUnion mounts in 4.4BSDLite.” In Proceedings of the USENIX Technical Conference on UNIXand Advanced Computing Systems. December 1995. 25-33. USENIX
Association.
[16] “unionfs-fuse” https://github.com/rpodgorny/unionfs-fuse.