Savefile.dat filesystem - why advanced fs choices?

Post#1 by **nanZor** » 08 Jul 2022, 08:17

When creating a savefile container, one is given the "advanced" options beyond the default of xfs, to choose ext2 ext4 or reiserfs.

But why? I guess I don't understand what the significance of choosing something other than xfs would be useful when a savefile container file itself is stored on fat / ntfs filesystem anyway.

Post#2 by **ncmprhnsbl** » 08 Jul 2022, 08:51

good question, for which i don't have a good answer

..beyond the original author liked to offer choices

. .
it would certainly make the scripting a heck of a lot simpler to just use xfs..

Post#3 by **babam** » 08 Jul 2022, 16:22

Only xfs works, containers with ext2, ext4 and reiserfs are broken.

Post#4 by **nanZor** » 09 Jul 2022, 04:50

I see - but I tried anyway just for kicks and saw something in common - even with xfs ..

Using ext2 / 4 or reseirfs, it *appears* to complete normally, but upon reboot in graphics mode, this error flies by:

"Changes not writable - using memory instead"

Here's the real kicker - when trying to resize an XFS savefile container, I made it smaller in size. It seemed to work! I changed the size from 4gb down to 2gb and sure enough, it is smaller.

HOWEVER, upon reboot - and the config referencing the same savefile, I get the *same* error as with the advanced filesystems. Changes not writable - using memory instead.

The permissions on this newly smaller-resized xfs container file is 777, rwx for user-group-other, but porteus is ignoring it now.

I'll have to experiment with an expansion of default xfs and see if that survives. But I can't really say what's going on..

Post#5 by **nanZor** » 09 Jul 2022, 05:36

Hmm.. tried making an existing working xfs savefile container larger in size. Uh oh, same result after reboot:

"Changes not writable - using memory instead"

Ok, moral for me is when using a savefile container is to make it XFS, and don't be skimpy with the initial size.

Interesting - I'll have to research this..

Post#6 by **nanZor** » 12 Jul 2022, 01:56

Unless anyone can convince me that anything but xfs is desirable to have as an option for a savefile container fs, and seeing how those other advanced fs options seem to be broken, I'm all for simplifying a dev's life by removing them and defaulting to xfs only.

I'm not sure that any users who puts a savefile container on a fat/ntfs partition, actually *cares* what FS the container itself uses - merely that is saves changes.

Just my .02c for whatever that's worth...

Post#7 by **nanZor** » 10 Nov 2023, 02:22

UPDATE: with LXDE 5.01, I had no problems changing the size of my initial xfs formatted container on fat32 from the default 512 to 3750mb. YES!!

5 hours laterrrrr..

EXT2 / 4 resizing works too! So happy.

But caught this in dmesg which might keep me up at night:

Code: Select all

xfs filesystem being mounted at /memory/changes supports timestamps until 2038-01-19 (0x7fffffff)

Oh no! Tossing and turning!

UPDATE: Personally, I'm sticking with xfs. I noticed that in Porteus Kiosk, if external usb media is configured, it will only recognize fat16/32, NTFS, or XFS. Without being a filesystem cheerleader, I think the dev knows what's up for a specific reason that goes beyond web-hype comparisons.