[Oberon] FPGA - Save / Restore OBERON.FS

[Skulski, Wojciech]

Paul wrote: 

>I map the entire filesystem into a single image file, 
> just by re-implementing the Kernel GetSector and PutSector routines,
> without changing the FileDir or Files modules.

The same approach was taken by the "Linux in a virtual box" implementations running under Windows. For example, coLinux or Virtual Box. I am using both VB and coLinux a lot. Their filesystems take the form of the .img files under Windows. Inside the .img file, Linux is maintaining the ext2 or ext3 filesystem. 

I found this approach very convenient for taking backups. I just zip an entire filesystem .img file and copy it into a backup storage. Typically, I can zip the 8-gig .img file into about one GB.

Just like Paul said, copying files between the Linux .img and the Windows side requires using tools such as samba, Secure Copy, or Filezilla. It is an extra step. It quite OK in practice. 

My biggest concern about Oeron FS is its limited size. 

Wojtek

________________________________________
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Paul Reed [paulreed at paddedcell.com]
Sent: Wednesday, April 19, 2017 8:36 PM
To: ETH Oberon and related systems
Subject: Re: [Oberon] FPGA - Save / Restore OBERON.FS

Hi Tomas,

> Probably yes, I was curious how original RISC.ing was produced as it
> has only used sectors in it, some 321?...So the creator must have had
> some fairly good guess, and I want to do the same.

When the original Oberon system was ported by members of ETH to commercial
personal computers, such as Unix, Macs, DOS and Windows, they chose to
implement Oberon file semantics on top of the host operating systems' file
systems in such a way as to conveniently expose Oberon files as individual
host files.

My cross-tools for generating the FPGA RISC Oberon filesystem image, on
the other hand, and most of my Oberon based compilers for that matter,
take a different approach: I map the entire filesystem into a single image
file, just by re-implementing the Kernel GetSector and PutSector routines,
without changing the FileDir or Files modules.

This simpler approach has served me well over the years, even though it
has the inconvenience (compared with the ETH method) that separate
utilities are needed to import and export host files to and from the
Oberon filesystem.  (When I started building Oberon tools, I needed them
to work on MS-DOS, where Oberon filenames could not easily even be mapped
to host filenames anyway!)

So when I create the RISC filesystem image, it is actually as a
side-effect of letting the Oberon tools run on what they think is an
Oberon system.  The reimplemented PutSector routine seeks to and writes
the relevant 1024-byte region of the image file - it is assumed that the
host operating system will fill-in any unused space, either with garbage
or zeros (those old enough - ahem - to have had the privilege of working
with, e.g. CP/M or TurboDOS would not assume this!). :)

The result is that the filesystem image naturally ends up being as big as
to include the highest sector number written, and that's what I append to
the 256MB protective FAT partition to create the SD-card image.  (See also
my previous post about the RISC.img format.)

If you want to use a raw copy program to copy all relevant sectors from
the image, but no more, to a backup image, you could as an exercise
replicate the operation of the FileDir Init procedure which is called at
startup.  This is effectively the garbage collection of the filesystem,
gathering and marking as allocated each sector of each file reachable from
the directory.  Chapter 7 of the book explains the disk allocation process
in detail.

I think it's great you are thinking about efficiency and not wasting disk
space: embedded systems programmers do not have the luxury of gigahertz
processors and terabytes of disk, and Oberon is certainly a model of
efficiency with many good lessons to learn - which can be effectively
applied in large systems as well.

On the other hand, often (especially in a commercial environment!) it's
more important to be pragmatic and choose your battles, which is why I
suggested copying the whole image; and Chris pointed out this can easily
be compressed.  Perhaps, for a quick but safe backup on a slow disk like
that of the Raspberry Pi, it might simply be necessary to re-order the
commands you use, ie pipe the raw image directly into the compression
software before writing the compressed output to disk.

HTH,
Paul


--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=NfdzU9eOCeHEVUX5KxsMfokQNxUUuktWORttDlDh9jg&s=64U89Eo8diqHvscpMsF-16U3wGXpq93Yi-Y-lQxF5ck&e=