You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This article describes limitations and known issues of BlobFuse.
19
+
This article describes the limitations and known issues of BlobFuse.
20
20
21
21
## Chmod operations in premium performance block blob accounts
22
22
23
-
Premium performance block blob accounts don't support access control lists (ACLs). BlobFuse returns success for `chmod` operations in those types of accounts.
23
+
Premium performance block blob accounts don't support access control lists (ACLs). However, BlobFuse returns success for `chmod` operations in these accounts even though the operations have no effect.
24
24
25
25
## Admin privilege required to interact with the fuse driver
26
26
27
-
When BlobFuse is mounted on a container, SYS_ADMIN privileges are required for it to interact with the fuse driver. If container is created without the privilege, mount will fail. Sample command to spawn a docker container is: `docker run -it --rm --cap-add=SYS_ADMIN --device=/dev/fuse --security-opt apparmor:unconfined <environment variables> <docker image>`
27
+
When you mount BlobFuse on a container, it requires SYS_ADMIN privileges to interact with the fuse driver. If you create the container without this privilege, the mount operation fails. Here's a sample command to spawn a Docker container with the required privileges:
28
28
29
-
## Limit on the number of containers that can be mounted in parallel
In case of `mount all` system may limit on number of containers you can mount in parallel (when you go above 100 containers). To increase this system limit use below command `echo 256 | sudo tee /proc/sys/fs/inotify/max_user_instances`
33
+
## Limit on the number of containers that you can mount in parallel
34
+
35
+
When you use the `mount all` command, the system might limit the number of containers that you can mount in parallel (typically when you exceed 100 containers). To increase this system limit, use the following command:
36
+
37
+
```bash
38
+
echo 256 | sudo tee /proc/sys/fs/inotify/max_user_instances
39
+
```
32
40
33
41
### Syslog and securing sensitive information
34
42
35
-
By default, BlobFuse will send logs to Syslog. The default settings will, in some cases, log relevant file paths to syslog. If this is sensitive information, turn off logging or set log-level to `log_err`.
43
+
By default, BlobFuse sends logs to syslog. The default settings might log file paths to syslog in some cases. If this information is sensitive, turn off logging or set the log-level to `log_err`.
36
44
37
45
## Unsupported file system operations
38
46
39
-
The following file system operations are not supported in BlobFuse:
40
-
41
-
`mknod`,`link (hard link api)`,`setxattr`,`getxattr`,`listxattr`,`removexattr`,`access`,`lock`,`bmap`,`ioctl`,`poll`,`write_buf`,`read_buf`,`flock`,`fallocate`,,`copyfilerange`,`lseek`
47
+
BlobFuse doesn't support the following file system operations:
48
+
49
+
-`mknod`
50
+
-`link` (hard link API)
51
+
-`setxattr`
52
+
-`getxattr`
53
+
-`listxattr`
54
+
-`removexattr`
55
+
-`access`
56
+
-`lock`
57
+
-`bmap`
58
+
-`ioctl`
59
+
-`poll`
60
+
-`write_buf`
61
+
-`read_buf`
62
+
-`flock`
63
+
-`fallocate`
64
+
-`copyfilerange`
65
+
-`lseek`
42
66
43
67
## Unsupported file system workflows
44
68
45
-
The following file system workflows aren't supported in BlobFuse:
46
-
47
-
- Creation of pipes, FIFO queues, Device files
48
-
49
-
- XAttrs for file or directory
50
-
51
-
- Hard links for file or directory
69
+
BlobFuse doesn't support the following file system workflows:
52
70
53
-
- Last access time and Last change time for any file or directory
71
+
- Creation of pipes, FIFO queues, and device files
72
+
- XAttrs for files or directories
73
+
- Hard links for files or directories
74
+
- Last access time and last change time for any file or directory
75
+
- Extended-attributes (x-attrs) operations
76
+
-`lseek()` operation on directory handles (no error is thrown, but it doesn't work as expected)
54
77
55
-
-`mkfifo` : fifo creation is not supported by BlobFuse and this will result in "function not implemented" error
78
+
### Specific command limitations
56
79
57
-
-`chown` : Change of ownership is not supported by Azure Storage hence BlobFuse does not support this.
58
-
59
-
- Creation of device files or pipes is not supported by BlobFuse.
60
-
61
-
- BlobFuse does not support extended-attributes (x-attrs) operations
62
-
63
-
- BlobFuse does not support lseek() operation on directory handles. No error is thrown but it will not work as expected.
80
+
-**`mkfifo`**: BlobFuse doesn't support FIFO creation and returns a "function not implemented" error.
81
+
-**`chown`**: Azure Storage doesn't support change of ownership, so BlobFuse doesn't support this operation.
64
82
65
83
## Altered behavior for some file system operations
66
84
67
-
The following file system operations have altered behavior in BlobFuse
85
+
The following file system operations have altered behavior in BlobFuse:
68
86
69
-
-`fsync()` force deletes file from local cache and invalidates attribute cache. This forces BlobFuse to refresh the file metadata and contents on next open call to that file.
70
-
71
-
-`fsyncdir()` invalidates metadata of that directory recursively. This forces BlobFuse to refresh metadata of any child of that directory on next metadata query by kernel.
87
+
-**`fsync()`**: Force deletes the file from local cache and invalidates the attribute cache. This action forces BlobFuse to refresh the file metadata and contents on the next open call to that file.
88
+
-**`fsyncdir()`**: Invalidates metadata of that directory recursively. This action forces BlobFuse to refresh metadata of any child of that directory on the next metadata query by the kernel.
72
89
73
90
## Unsupported scenarios
74
91
75
-
-BlobFuse does not support overlapping mount paths. While running multiple instances of BlobFuse make sure each instance has a unique and non-overlapping mount point.
92
+
-**Overlapping mount paths**: BlobFuse doesn't support overlapping mount paths. When running multiple instances of BlobFuse, ensure each instance has a unique and nonoverlapping mount point.
76
93
77
-
-BlobFuse does not support co-existence with NFS on same mount path. Behavior in this case is undefined.
94
+
-**Co-existence with NFS**: BlobFuse doesn't support coexistence with NFS on the same mount path. The behavior in this case is undefined.
78
95
79
-
- For storage accounts that have a flat namespace, when data is uploaded through other means, BlobFuse expects special directory marker files to exist in container. For example, if you have a blob `A/B/c.txt` then special marker files shall exist for `A` and `A/B`. To overcome this requirement, BlobFuse uses ListBlob aoi instead of GetBlobProperties api for `ls`operation though `ListBlob` is more expensive.
96
+
-**Flat namespace storage accounts**: For storage accounts that have a flat namespace, when you upload data through other means, BlobFuse expects special directory marker files to exist in the container. For example, if you have a blob `A/B/c.txt`, then special marker files should exist for `A` and `A/B`. To overcome this requirement, BlobFuse uses the ListBlob API instead of the GetBlobProperties API for `ls`operations, though ListBlob is more expensive.
80
97
81
-
- For storage accounts that have a flat namespace, `--virtual-directory=false`cli flag or `virtual-directory=false` option under `azstorage` section can be used to switch from `ListBlob` api to `GetBlobProperties` api but in absence of special directory marker, BlobFuse will fail to identify directories. A possible workaround to resolve this from your container is to either create the directory marker files manually through portal or run `mkdir` command for `A` and `A/B` from BlobFuse. Refer [me](https://github.com/Azure/azure-storage-fuse/issues/866) for details on this.
98
+
-**Virtual directory configuration**: For storage accounts that have a flat namespace, you can use the `--virtual-directory=false`CLI flag or the `virtual-directory=false` option under the `azstorage` section to switch from the ListBlob API to the GetBlobProperties API. However, in the absence of special directory markers, BlobFuse can't identify directories. A possible workaround is to either create the directory marker files manually through the portal or run the `mkdir` command for `A` and `A/B` from BlobFuse. For more information, see [this GitHub issue](https://github.com/Azure/azure-storage-fuse/issues/866).
82
99
83
-
- On non-HNS accounts chmod operations are not permitted and BlobFuse will return back success in such cases.
100
+
-**Non-HNS accounts**: On non-HNS (hierarchical namespace) accounts, chmod operations aren't permitted, and BlobFuse returns success in such cases without actually performing the operation.
84
101
85
102
## Breaking changes
86
103
87
-
_direct_io_: To improve performance of repetitive reads from a file BlobFuse utilizes kernel cache. Kernel page cache can only be turned on or off but cannot be controlled by timeout-based expiry. This creates an issue in environment where you wish to sync the latest file from container to your local mount. As long as kernel cache is valid, kernel will not ask for new contents from underlying filesystem (BlobFuse in our case).
104
+
### Direct I/O and caching behavior
105
+
106
+
To improve performance of repetitive reads from a file, BlobFuse utilizes kernel cache. The kernel page cache can only be turned on or off but can't be controlled by timeout-based expiry. This limitation creates an issue in environments where you want to sync the latest file from the container to your local mount. As long as the kernel cache is valid, the kernel doesn't request new contents from the underlying filesystem (BlobFuse).
88
107
89
-
To disable the kernel data cache_direct_io_ is the option most customer use. Other than data cache, kernel also maintains a metadata cache. This metadata cache is driven by timeouts configured using `attribute_timeout`, `entry_timeout` and `negative_timeout`. If user wants immediate refresh of contents, then they need to set all these timeouts to 0 as well along with using _direct_io_. With these configuration parameters kernellevel caching will be disabled and on top of this user also have to disable BlobFuselevel caching (file_cache and attr_cache) with timeouts for them set to 0
108
+
To disable the kernel data cache, use the `direct_io` option. Besides the data cache, the kernel also maintains a metadata cache. This metadata cache is driven by timeouts configured by using `attribute_timeout`, `entry_timeout`, and `negative_timeout`. If you want an immediate refresh of contents, set all these timeouts to 0 along with using `direct_io`. With these configuration parameters, kernel-level caching is disabled. Additionally, you also have to disable BlobFuse-level caching (`file_cache` and `attr_cache`) with their timeouts set to 0.
90
109
91
-
This means to disable all caching; user needs to configure roughly seven parameters. To simplify this, as part of _auto config_feature in version 2.4.0 we started disabling everything when user gives _direct_io_option. This was to simplify the customer experience, which earlier was generating some issues and complains about the config being too complicated.
110
+
To disable all caching, you need to configure roughly seven parameters. To simplify this process, the auto config feature in version 2.4.0 disables everything when you use the `direct_io`option. This change simplifies the customer experience, which previously generated issues and complaints about the configuration being too complicated.
92
111
93
-
However, with this change as both kernel and BlobFuse caching is disabled, BlobFuse started making more calls to storage. This had a cost impact on the customer where higher number of calls were not only degrading performance but were increasing the bill as well. To fix this with correct measures with version 2.5.0 we have introduced a new cli parameter called _disable-kernel-cache_ which only disables kernellevel data and metadata caching and then you can control BlobFuselevel caching with file-cache timeout and attr-cache timeout values. This allows you to refresh the contents as per your application needs. For example, if the application is fine, and the contents are refreshed in five seconds, then set the file and attribute cache timeouts to five seconds and use this new cli flag. With this your application will get refreshed contents in five seconds and cost will also be under control.
112
+
However, this change disables both kernel and BlobFuse caching, so BlobFuse starts making more calls to storage. This change has a cost impact on customers where the higher number of calls not only degrades performance but also increases costs. To address this problem, version 2.5.0 introduces a new CLI parameter called `disable-kernel-cache`, which only disables kernel-level data and metadata caching. You can then control BlobFuse-level caching by using file-cache timeout and attr-cache timeout values. This configuration allows you to refresh the contents according to your application needs. For example, if your application is fine with contents being refreshed every five seconds, set the file and attribute cache timeouts to five seconds and use this new CLI flag. With this configuration, your application gets refreshed contents every five seconds while keeping costs under control.
94
113
95
114
## Synchronizing with data written by other APIs
96
115
97
-
BlobFuse supports read and write operations. Continuous synchronization of data written to storage by using other APIs or other mounts of BlobFuse isn't guaranteed. For data integrity, we recommend that multiple sources don't modify the same blob, especially at the same time. If one or more applications attempt to write to the same file simultaneously, the results might be unexpected. Depending on the timing of multiple write operations and the freshness of the cache for each operation, the result might be that the last writer wins and previous writes are lost, or generally that the updated file isn't in the intended state.
116
+
BlobFuse supports read and write operations. However, continuous synchronization of data written to storage by using other APIs or other mounts of BlobFuse isn't guaranteed. For data integrity, don't modify the same blob from multiple sources, especially simultaneously. If one or more applications attempt to write to the same file at the same time, the results might be unexpected. Depending on the timing of multiple write operations and the freshness of the cache for each operation, the result might be that the last writer wins and previous writes are lost, or that the updated file isn't in the intended state.
0 commit comments