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.
Savefile.dat filesystem - why advanced fs choices?
Savefile.dat filesystem - why advanced fs choices?
That's a UNIX book - cool. -Garth
- ncmprhnsbl
- DEV Team
- Posts: 3941
- Joined: 20 Mar 2012, 03:42
- Distribution: v5.0-64bit
- Location: australia
- Contact:
Savefile.dat filesystem - why advanced fs choices?
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..
it would certainly make the scripting a heck of a lot simpler to just use xfs..
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44
- babam
- Warlord
- Posts: 528
- Joined: 16 Nov 2016, 10:30
- Distribution: Porteus 5.0rc3 Xfce K6.1.1
- Location: Rainy city
Savefile.dat filesystem - why advanced fs choices?
Only xfs works, containers with ext2, ext4 and reiserfs are broken.
Sorry, my English is bad.
Savefile.dat filesystem - why advanced fs choices?
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..
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..
That's a UNIX book - cool. -Garth
Savefile.dat filesystem - why advanced fs choices?
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..
"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..
That's a UNIX book - cool. -Garth
Savefile.dat filesystem - why advanced fs choices?
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...
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...
That's a UNIX book - cool. -Garth
Savefile.dat filesystem - why advanced fs choices?
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:
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.
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)
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.
That's a UNIX book - cool. -Garth