We have troubles to store more then 200-300 files in one folder. In case there is about 1000-10000 files in one folder, it is almost impossible to read/write/download files. Is there any plan to have F2FS nebo ext4 for User partition?
To be honest, I doubt that. If you have a “higher” use case to store 10,000+ files in one folder, I would try to take into consideration an external USB stick—or even better, external data storage.
Hi,
as Jaroslav said, I’m also not aware of any plans changing the PLCs filesystem.
But nevertheless I’m asking back because of the impossibility of “read / write”: can you give us some more background information about that?
I can confirm that we always suggest to use different subfolders for a bunch of files around 200-300 files.
But from my knowledge (which is quite old, based on a support case some years ago) the usage of DirXXX function blocks slowed down the handling of files within one folder, when the amount of files was greater then 200-300 per folder (as I remember, the root cause is a limitation of the FAT filesystem and how they handle files per folder, which lead to exponential processing time when gathering directory information, if the number of files exceeds “some 100 per directory”).
As DirXXX function blocks are also used within some mapp functionality (like mapp file explorer), and maybe also by the FTP server (that’s just my guess), usage of those functions will also lead to the same behavior.
But, and that’s the question why I’m asking: we’ve never had such behavior with read / write functionality when filenames were known and accessed directly by application, so no need for the usage of DirXXX functions where given.
Do you have a different behavior in your usecase?
Best regards!
1 Like
The easiest file systems to be added for Automatoin Runtime support would be the ones natively supported by VxWorks ( DosFS - FAT12, FAT16 and FAT32 support, HRFS, NFS, RAWFS, CDROMFS, TFFS). Anything else would be highly unlikely, speaking from my experience.
Since DosFS is already used to support FAT32, the next likely one I could see might be HRFS, but that would likely run into filesystem issues when trying to mount a removable media on windows, as it’s not a native file system for windows.
There are other third parties that have developed more advanced file systems with modern (i.e ZFS, BTRFS, BCACHESFS, APFS) features like Copy-On-Write or snapshots, but would run into the problems of not being natively supported by VxWorks or Windows.
1 Like
The problem I had wirh mprecipe, mpData. Lot of files caused a increasing of reading data. For example 450 recipes → load time was abou 2-4 seconds.
Hi @Vratislav, have you found usable solution for you, can you update us?
Closed due to inactivity. If you have not found a solution, please get in touch with the support of your local B&R office. It would be great if you could update us with any findings or solutions. Thanks, Jaroslav
didnt find solution. it is problem of filesystem itself.