disable journalling?

Of course it is, but the journalling is not a mount option but an fs option. It is edited using tune2fs. You need to unmount the fs before doing that, which is obviously not possible on a Pi.

(on a PC you would boot from CDROM and do it from there)

I'm afraid that's contrary to my experience. Perhaps you're recalling early DOS versions compounded by running it on disks with bad sectors?

I'm quite confident in the versions current from as far back as win95OSR2. Indeed, it proved to be quite bombproof a few years back when I was dealing with a system that had a peculiar instability induced by a compatability issue between the hard disk controller and the detected UDMA mode which caused random system lockups (but, not so random when running defrag).

Having found something (defrag) that would make the issue 'repeatable', I used it to good effect to determine an effective cure.

In the process of repeated lockups during defrag attempts, I never once saw any issues of data loss (nor did the ensuing CHKDSK /R scan have to fix any problems, validating the robustness of the algorithms used by defrag).

--
Regards, J B Good

The case I'm thinking of was a brand new Olivetti, but I don't now remember it is was running WfW 3.11 or W95 - it was certainly in 1994. We'd been using the machine for less than a week when this happened. I don't recall how the disk got corrupted - not my PC - and I'm not ever sure it was a crash. Anyway, Windows was a bit unhappy but was running, so we tried the Windows defragger and 5 minutes later the disk was completely unusable. Can't have been a bad disk, because we reformatted it and reinstalled Windows and applications successfully. That wasn't the only M$ defrag disaster I've seen - just the one I remember best.

After that it was a matter of 'once bitten, twice shy' and I've never used a M$ defragger since - why bother when the one in Norton Utilities was so much better.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

So, MSDOS 6.xx and WFWG then (win95 didn't appear until August '95 - the year it was _supposed_to_ ship - the proper version with FAT32 support didn't appear until a year later).

I think the dos version of defrag was prone to trashing the data if the FS had uncorrected consistency errors. It was always best to run scandisk beforehand to make sure FS errors weren't lying in wait to screw up the defrag run.

With WFWG, I don't believe there ever was a windows version of defrag. You needed to exit the windows shell before running defrag from the command line.

I can't recall whether the windows shell would prevent defrag being launched but I suspect that if it didn't and you launched it from within windows without windows closing automatically to dump you back to DOS, you'd likely suffer corruption from windows' background activity interfering with the defrag activity. It's all so long ago now so ICBW.

Agreed! I must admit that I preferred Peter Norton's defrag tool over the MS one when dealing with FAT volumes. I suspect the defrag tool in win95OSR2 was vastly improved over the earlier DOS versions (but, again, this was a long time ago so only have a hazy impression that this was so).

Certainly by the time I discovered the joys of win2KSP4 sometime around 2004/5, I had every confidence in the MS defrag utility and stopped using the Peter Norton utilities, probably coincident with Peter selling out to Symantec around that time.

My experience with defrag's robustness as a test tool on that problematic system I was refurbishing (winXP most likely to be the installed OS but possibly win2k) only strengthened my confidence in the windows version of defrag. I've certainly never been given cause to doubt its reliabilty since at least the days of win95OSR2.

--
Regards, J B Good

One option would be to cleanly shut down the Pi, move the SD card to another machine, disable journaling, then, move the SD card back to the Pi.

I wasn't able to find a definitive reference, but ISTR it is _NOT_ necessary to unmount the filesystem before disabling the journal. However, YMMV. Worst case, if you have another machine available, you could back up the SD card, try it, and restore the SD card if things went badly. Then again, it would be easier to follow my first suggestion with that setup.

HTH

--
Robert Riches 
spamtrap42@jacob21819.net 
(Yes, that is one of my email addresses.)

Yes, but that other machine cannot be a Pi either. You would need another machine, with an SD card reader, and running Linux (or at least booted from a Linux CD)

And when you read my original posting in detail, I mentioned that the Pi is located remotely. I have two here at home on which I can develop and test the procedure, but ultimately it will have to be performed over an SSH session on a physically inaccessible Pi.

Of course I make regular backups of the relevant parts of the system.

I just would like the Pi stop writing to the journal. I don't mind when the area reserved for journalling will remain allocated and not returned to the free space (as the document procedure does).

WinME's defrag is better than w98's, which I feel was the same as w95's; you might want to post to a w98 group!

FU's set.

--
It's a money /life balance.

I personally think it's a bad idea to remove the journal. In 2 years of using Pi's I've not experienced any SD card wear-out. If you're making a device for "embedded" use then consider a read-only root filing system (google for it - it's been done several times, and I know folks who are doing just that for large display signs with a RPi embedded in them).

However if you really want to do it, then the easiest way is to get another PC running Linux with an SD card reader.

Insert the Pi's SD card then do this:

fsck -fC /dev/mmcblk0p2

(Assumes the SD card is /dev/mmcblk0 - it might be /dev/sdb, etc. depending on the SD card reader you use)

You do the FSCK to make sure the system is clean and any existing journal is played back.

Then to disable the journal:

tune2fs -O ^has_journal /dev/mmcblk0p2

run another fsck:

fsck -fC /dev/mmcblk0p2

and that's it. Job Done. Put it back in the Pi and off you go. Slower with something that will take longer to boot if it crashes.

Gordon

I seem to recall this being configurable bo don recall ever encoutering a format that didn't use 512.

I've never heard of FAT-8 -- was it something from MS-DOS 1.0 ?

FAT-12 could handle upto 4096 allocation units (aka clusters), for disks upto 2 megytes in size it was one sector per cluster.

FAT table copies were optional too

--
Neither the pheasant plucker, nor the pheasant plucker's son.

My Pi is a web/mail/time/whatever server and it needs a r/w filesystem. However, it does not need journalling.

I know that solution, I have found it using Google.

Most probably PC-DOS 1 and in relation to floppy disk storage.

Funnily enough, I re-invented a FAT8 system for a solenoid controlled data cassette deck File System in the early 80s to use with a Transam Tuscan S100 kit built computer.

It's possible that my friend who'd given me helpful hints on creating a file system may have been familiar with the PC-DOS FAT8 FS (I don't recall him mentioning FAT8 or DOS specifically) so it might not have been the coincidence it seems to be in retrospect.

In this case the physical block size was 2KB so an 8 bit pointer in what I called the LNKTBL (FAT in MS's terminology) was more than ample to address the 168 blocks each side of a C60 sized data cassette tape (332KB max usable capacity a couple of the 2k blocks were used to duplicate the directory and LNKTBL data. The duplication being required to avoid unrecoverable FS errors in the event of a crash or power outage mid write.

I don't think that was _ever_ true. The FATs _had_ to be duplicated simply to guard against the very real and ever present risk of crashes or power outage mid write as per my own tape FS.

Despite its apparent fragileness, it nevertheless served its function quite well in practice. As long as you ran a FS consistency check (scandisk or chkdsk) upon resumption from a crash or unforeseen power loss, the FAT duplication did an effective enough job.

True, it may not have had as much redundency in the FS as its CP/M predecessor (which, imo, seemed to have a wasteful amount of redundency at a time when CPU grunt was provided by 8 bit 2MHz clocked

8080 or Z80 chips) but it proved sufficient in practice for all intents and purposes.

In all my years of experience with FAT, I've never considered it to be "A bloody nightmare". I've created enough Frankenstein monstrousities in my time and done my fair share of scandisk/chkdsk FS repairs and can only recall one event where I lost data due to FS trouble on a FAT32 volume on a disk that had generated bad clusters due to being overheated by a mere 5 deg at most.

Luckily, the one folder's worth of data that proved irretreivable just happened to be backed up on another drive so no net loss of data.

Admittedly the NTFS volume, once I'd sorted out a testbed PC to run the job on, proved to be the more successful chkdsk run with no data loss involved. FAT only becomes "A Nightmare" when run on unstable systems in the habit of frequently crashing at the slightest provocation, a system no self respecting user would want to trust his precious data to anyway.

--
Regards, J B Good

I suppose "another PC running Linux" could be a Pi with a USB CF adapter.

--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

Most likely. I don't think I've ever seen it: only heard of it and at

256 sectors it would have been a rather small disk. All I know was that it was around right at the start of MS-DOS, certainly before my time.

I don't remember using any DOS box before 1986, and that was almost certainly a 12MHz PC-AT and using those new-fangled 1.2 MB floppy disks.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

s/CF/SD

Yes, that works - I was playing with it the other day. The card in the USB card reader becomes /dev/sda but you'll have to mount its partitions manually, e.g. as root:

mkdir /part1 /part2 mount -t vfat /dev/sda1 /part1 mount -t ext4 /dev/sda2 /part2

# do stuff to prove its mounted and accessible and then

umount /dev/sda1 umount /dev/sda2 rmdir /part1 /part2

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

It's certaily true now: see the man page for mkdosfs

and this page from Microsoft.

--
Neither the pheasant plucker, nor the pheasant plucker's son.

Bear in mind that the FAT file system originated in the pre-DOS Microsoft disk BASICs.

--
roger ivie 
rivie@ridgenet.net

pretty sure it existed on floppy disks from the CP/M era

And whatever that was based on..

--
Ineptocracy 

(in-ep-toc?-ra-cy) ? a system of government where the least capable to  
lead are elected by the least capable of producing, and where the  
members of society least likely to sustain themselves or succeed, are  
rewarded with goods and services paid for by the confiscated wealth of a  
diminishing number of producers.

Sorry for missing that point. I think I read that a few days ago but had forgotten the connection between that point and your more recent posting.

One potential idea to mitigate the increased risk due to disabling the journal might be to (re)mount the filesystem in synchronous mode, if the performance impact was tolerable.

Good luck.

--
Robert Riches 
spamtrap42@jacob21819.net 
(Yes, that is one of my email addresses.)

CP/M doesn't use the FAT filesystem.

--
roger ivie 
rivie@ridgenet.net