Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Mon 11 Nov 2019, 21:18
All times are UTC - 4
 Forum index » House Training » Users ( For the regulars )
What are SFS files for? 2fs files? pupsave files?
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [6 Posts]  
Author Message
svgt

Joined: 26 Mar 2008
Posts: 113
Location: Hamburg, Germany

PostPosted: Sun 11 Oct 2009, 16:51    Post subject:  What are SFS files for? 2fs files? pupsave files?  

What is the meaning of the sfs suffix? What is the special meaning of 2fs suffix?

What is the reason for the pupsave-files?

Regards,
Svgt
Back to top
View user's profile Send private message 
Dingo


Joined: 11 Dec 2007
Posts: 1439
Location: somewhere at the end of rainbow...

PostPosted: Sun 11 Oct 2009, 16:58    Post subject: Re: SFS files  

svgt wrote:
What is the meaning of the sfs suffix? What is the special meaning of 2fs suffix?

What is the reason for the pupsave-files?

Regards,
Svgt


1° squash filesystem
2° Ext2 filesystem
3° to avoid "OH MY GOD! TRYING TO INSTALL UBUNTU I WIPED MY HARD DRIVE WITH ALL MY DATA!" typically said by users just leaved or running windows when a bad friend say INSTALL UBUNTU!

_________________
replace .co.cc with .info to get access to stuff I posted in forum
dropbox 2GB free
OpenOffice for Puppy Linux
Back to top
View user's profile Send private message Visit poster's website 
rufwoof


Joined: 24 Feb 2014
Posts: 3610

PostPosted: Tue 05 Mar 2019, 06:55    Post subject:  

Reviving a old thread as outlines of sfs appear distinctly lacking given the extensive use of such in Puppy land.

sfs - squashed file system.

Filesystem - layout/structure that is known by the kernel (operating system) for how directories/files/data are laid out.

A Linux filesystem (very basically) comprises Directory blocks, that contain filenames and a inode pointer

inodes contain pointers to where the file data is actually stored (data blocks).

When a file system is mounted, the system becomes 'aware' of the directory blocks. When you (system) access a filename, the directory block indicates the first inode to access, which points to where the first part of the file (data) actually resides. Multiple inodes/data blocks are then chained as required in sufficient number to accommodate the amount of data being stored in that filename. [In practice inodes are limited in number and "Indirects" can be used i.e. dynamically allocated additional blocks of inodes - but that just complicates what I'm looking to overview here].

In a read/write filesystem that can all dynamically change as files are changed, moved around or deleted.

A squashed filesystem uses compression applied to (optionally) the directories, inodes and file data. Compression basically (again at a very simplistic level) replaces sequences of bytes with codes. In a 256 code compression table for instance byte FF hex might be associated to a character sequence of "the", such that 3 bytes sequences of "the" are replaced with a single byte value of FF hex. (The code table also has to be stored as part of that).

Compression applied to a collective filesystems Directory, inode, data is known as a squashed filesystem. The kernel (operating system) knows how to handle that (assuming its coded to do so), the same as any other filesystem it knows about (ext2, ext3, ext4 ...etc.). Unlike read/write filesystems however, once compressed the squashed filesystem is static - read only. Unless that is it is fully extracted (unsquashfs), changes made and then reformed again (mksquashfs).

Linux makes extensive use of disk cache. Once a file has been read in once, it is kept in memory, only being ejected if memory is required for other things. Typically the cache that is freed for other things is selected according to a least used (accessed) algorithm. So when a sfs is first loaded, decompressed directory blocks that are accessed often, are more likely to remain memory resident. As are the inodes (pointers). Primarily therefore reading files out of a squashed filesystem in a running system primarily involves reading in compressed data from where the memory resident directory and inodes point, and decompressing that file content data (assuming its not already memory bound (cached)).

Typically compression halves the amount of data (broad average) and reading half as much data from disk and then decompressing that can take a comparable amount of time to just reading twice as much data without having to decompress it. Such that the 'overhead' of having to decompress things can narrow down to zero in regards to time taken to 'read a file'.

So fundamentally sfs's are just filesystems, that have been compressed. Which can be opened (mounted) as any other supported filesystem, but that are read only (whereas other filesystems are dynamic (read/write)). Alternatively a sfs can be union mounted, which in effect combines two folders together, where the sfs is mounted and a empty (or pre-existing) folder where changes can be recorded is combined with that, along with a third folder/directory - that is used as what the system/you actually see. Initially such a arrangement might have a completely empty changes (rw) folder content, so everything from the sfs mount point shines through to the top visible folder/tree. If you add a file then that is recorded in the read/write folder, so that it also shines through to the top level. If a file is changed then two copies of that file exist, one (the original read only version) in the sfs, another in the rw ... has the rw version taking precedence as to the one that shines through to the visible layer. If a file is deleted, it still is in the sfs, but a whiteout (.wh) file is created in the rw layer so that the system knows that file should be excluded from shining through to the visible layer. readme.txt in the sfs, .wh.readme.txt in the rw ... and no readme.txt file is visible in the top layer.

A sfs is therefore a compressed set of files/directories/data that are all combined into a single file (filesystem). A bit like a self contained disk, that can be mounted/unmounted as desired, but where the content is static (read only). Mounting/loading a sfs is like inserting a physical additional disk into the current running system. Puppy however actually typically uses a sfs to contain the main system. In older MBR/BIOS systems for instance you power up and BIOS triggers the MBR (512 bytes of code) that include partition (disk) layout pointers, that (in the case of grub4dos bootloader) points to grldr (chain loading), that points to a vmlinuz (kernel/OS), that loads and runs init (inside initrd), that mounts a sfs containing the main puppy system. Typically init then switch-root's to that mounted sfs, similar in some respects to chroot, where the OS switches over to treating a sub-directory (folder) as though it were the root folder (/).

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh

Last edited by rufwoof on Mon 07 Oct 2019, 17:30; edited 1 time in total
Back to top
View user's profile Send private message 
bigpup


Joined: 11 Oct 2009
Posts: 12824
Location: S.C. USA

PostPosted: Tue 05 Mar 2019, 09:53    Post subject:  

Quote:
What is the special meaning of 2fs suffix?
What is the reason for the pupsave-files?

When Puppy Linux is installed as a frugal install.
All the Puppy files are loaded as read only.
When you make changes, settings, add programs, etc.....
They are written to a Puppy save.
The save is read/write loaded.
The Puppy save is what the frugal install uses as storage location.

One option for the Puppy save is to make it a sfs file.
Inside this file is actually a Linux file system setup.
It could be Ext 2, 3, or 4 file system.
When the Puppy sfs save file is made.
The .sfs suffix is named to identify what Linux file system is in the sfs.
2fs is ext 2.
3fs is ext 3.
4fs is ext 4.

_________________
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected Shocked
YaPI(any iso installer) http://www.murga-linux.com/puppy/viewtopic.php?t=107601
Back to top
View user's profile Send private message 
nic007


Joined: 13 Nov 2011
Posts: 3108
Location: Cradle of Humankind

PostPosted: Tue 05 Mar 2019, 10:32    Post subject:  

SFS is a read-only archive format (the contents are compressed). 2fs, 3fs and 4fs are uncompressed linux filesystems. Savefiles have the 2fs, 3fs or 4fs extension (depending on which one you are using) and have read and write capabilities.
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3610

PostPosted: Mon 07 Oct 2019, 17:55    Post subject:  

A sfs has a superblock of around 100 bytes at the start of the file (varies slightly according to which compression method/parameters are being used) that describes its content (compression method used, start of Directory region, start of inode region ...etc.).

The Directory region contains alphabetically sorted filenames and a associated inode pointer (offset into the inodes table where the inode for a particular file is stored) for each file.

A basic file inode contains a 32 bit offset pointer from the start of the archive (sfs) file where the data blocks for a particular file is stored within the archive, along with a filesize value for the files uncompressed filesize. Compressed single file data is stored sequentially within the data region so the inode only needs to store the position of the first block.

So having looked up the Directory entry for a particular filename, the associated inode is accessed and that inode points to the start (from the beginning of the archive file) of the compressed data, which is sequentially read and uncompressed (output) .. until the 'uncompressed filesize' number of bytes have been output.

Whilst there's decompression processing involved, typically compression halves the size of data, so reading half as much data from (slow) disk (IO) and decompressing that to twice the size (uncompressed actual data values) in memory can be quicker overall compared to reading twice as much uncompressed data from disk without having to decompress that.

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 1 [6 Posts]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » House Training » Users ( For the regulars )
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0475s ][ Queries: 12 (0.0082s) ][ GZIP on ]