Closed itmagpro closed 1 month ago
sorry, i dont understand this request.
?;( what not understand? next lines from your README.md
File size is preserved to work around applications that do size checks:
# dd if=/dev/zero of=/nullfs/DATA bs=1M count=20
20+0 records in
20+0 records out
20971520 bytes (21 MB, 20 MiB) copied, 0.00392452 s, 5.3 GB/s
# stat -c%s /nullfs/DATA
20971520
Reading from the files does not copy anything to userspace and is an NOOP; makes it behave like reading from /dev/zero:
# dd if=/nullfs/DATA of=/tmp/REALFILE
40960+0 records in
40960+0 records out
20971520 bytes (21 MB, 20 MiB) copied, 0.0455288 s, 461 MB/s
# hexdump -C /tmp/REALFILE
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
that /nullfs/DATA exist, htis you understand?
$ mount|grep null
none on /mnt/nullfs type nullfs (rw,relatime)
$ touch /mnt/nullfs/test/file
$ pv < /dev/zero > /mnt/nullfs/test/file
840GiB 0:01:39 [11.5GiB/s] [ <=>
$ cat /mnt/nullfs/test/file
...LONG WAIT...
^C <<<--- INTERRUPT by CTRL+C
$ ls -la /mnt/nullfs/test/file
-rw-r--r-- 1 test test 1277012344832 Sep 25 13:38 /mnt/nullfs/test/file
need without ...LONG WAIT...
the data does not exist in reality, it just fakes the size of the file. Reading from the file only returns zeroes. No data is stored whatsoever.
This kernel module behaves like /dev/null just that it allows you to create files and directories as in, creating a directory structure. It does not save any data, it just behaves like it would.
Using cat on the files is essentially similar to cat /dev/zero, until file size that is preserved is reached, and this is intended behavior. The module is usually used to do performance testing of userspace applications where you want to rule out any performance bottlenecks from the kernel space.
If you want to change reading behavior to return immediately without returning zeroes until the complete file is read by the userspace application, change this function to return immediately:
https://github.com/abbbi/nullfsvfs/blob/master/nullfs.c#L174
i dont intend to do so, because its not the usecase for this module (measuring read and write performance of userspace applications).
simple cat to stdout of files stored on nullfsvfs is not good idea bcs it sends all the zeroes to your terminal, which probably ends up eating 100% cpu, making it slow.
redirect data to some endpoint to make it fast:
cat /mnt/nullfs/test/file > /dev/null
This same thing, that need:
sudo umount /mnt/nullfs
sudo rmmod nullfs.ko
sudo make clean
$ sudo make clean
make -C /lib/modules/4.19.0-27-amd64/build M=/opt/nullfsvfs-0.17 clean
make[1]: Entering directory '/usr/src/linux-headers-4.19.0-27-amd64'
CLEAN /opt/nullfsvfs-0.17/.tmp_versions
CLEAN /opt/nullfsvfs-0.17/Module.symvers
make[1]: Leaving directory '/usr/src/linux-headers-4.19.0-27-amd64'
line 174
sudo vi nullfs.c
...
static ssize_t read_null(struct file *filp, char *buf,
size_t count, loff_t *offset) {
/**
* Pretend we have returned some data
* during file read
**/
int nbytes;
struct inode * inode = filp->f_inode;
return 0; <<<--- ADD THIS
...
}
$ sudo make
$ sudo insmod nullfs.ko
$ sudo mount -t nullfs none /mnt/nullfs -o mode=777
$ mount|grep null
none on /mnt/nullfs type nullfs (rw,relatime,mode=777)
$ mkdir /mnt/nullfs/test
$ touch /mnt/nullfs/test/file
$ echo foobar > /mnt/nullfs/test/file
$ pv < /dev/zero > /mnt/nullfs/test/file
^C.0GiB 0:00:10 [10.3GiB/s] [<=>]
$ ls -la /mnt/nullfs/test/file
-rw-r--r-- 1 test test 81385488384 Sep 25 22:57 /mnt/nullfs/test/file
$ cat /mnt/nullfs/test/file
$
Thank, Bro and gud luck! :)
This same thing, that need:
like said, this will return immedately upon any read() done by an application. Your change sets the amount of bytes that are returned by the kernel to 0. If an application that reads data from the FS with this change and checks the size, this will break the userspace application (not cat).
The cat command you are using writes to stdout, which is slow because your terminal is eating away cpu time to handle the zeroes. You can have fast read from the files by simply redirecting the cat output (cat /mnt/nullfs/test/file > /dev/null) without your change.
If an application that reads data from this filesystem checks the size, this will break the userspace application (not cat).
It this why I before ask about total blackhole directory, where all files disappear/gone like in /dev/null
But in any way userspace application may be break when read fake 000...data instead expected real data like JSON/HTML/TXT/etc
The cat you are using writes to stdout making it slow because...
Because any way some time need for read zeroes via cat/less/php or some etc programms.
It this why I before ask about total blackhole directory -
:)
...add some function in code and new supported mount options
The following mount options are supported:
-o mode= set permissions on mount directory ( mount .. -o mode=777 )
-o uid= set uid on mount directory ( mount .. -o uid=1000 )
-o gid= set gid on mount directory ( mount .. -o gid=1000 )
-o write=fn keep data for specific file ( mount .. -o write=fstab )
...NEW_OPT_HERE... some like -persist=no (no save in nullfs any dirs or files)
...or if not.., then renamed project from nullfsvfs to virtualfsvfs, may be zerofsvfs or some thing else :)
Hello, Bro!
For example:
instead long read fake null data from virtual fake file, the best solution - file must dissappear forever.
This scenario posible?