Carlos Konstanski on 28 Feb 2005 00:35:35 -0000


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] OSX "middleware"?


Got that patch for disabling fsck in the HFS filesystem driver.  Looks
pretty basic.  The file is /usr/src/linux/fs/hfsplus/super.c :

251,253c251,254
< 			       "running fsck.hfsplus is recommended.  leaving read-only.\n");
< 			sb->s_flags |= MS_RDONLY;
< 			*flags |= MS_RDONLY;
---
> 			       "running fsck.hfsplus is recommended. Not mounting read-only because there is no way to check the filesystem."
> 			       "\n");
> //			sb->s_flags |= MS_RDONLY;
> //			*flags |= MS_RDONLY;
255,257c256,258
< 			printk("HFS+-fs: Filesystem is marked locked, leaving read-only.\n");
< 			sb->s_flags |= MS_RDONLY;
< 			*flags |= MS_RDONLY;
---
> 			printk("HFS+-fs: Filesystem is marked locked, be careful when making changes..\n");
> //			sb->s_flags |= MS_RDONLY;
> //			*flags |= MS_RDONLY;
337,338c338,339
< 			       "running fsck.hfsplus is recommended.  mounting read-only.\n");
< 		sb->s_flags |= MS_RDONLY;
---
> 			       "running fsck.hfsplus is recommended. Not mounting read-only.\n");
> //		sb->s_flags |= MS_RDONLY;
341,342c342,343
< 			printk("HFS+-fs: Filesystem is marked locked, mounting read-only.\n");
< 		sb->s_flags |= MS_RDONLY;
---
> 			printk("HFS+-fs: Filesystem is marked locked, be careful when making changes..\n");
> //		sb->s_flags |= MS_RDONLY;

Looks like he changed a few messages to the user, and commented out any
place in the code where the sb->s_flags flag gets masked with MS_RDONLY.
My guess is that write functions in the API will not perform a write if
this flag is set.  By commenting out all the places where this flag
could get set, he avoids the problem of write functions refusing to
write.

A hack?  Sure, but hopefully its useful lifespan will be short.  All we
need is an fsck.hfsplus program.

On Thu, 24 Feb 2005, Mark M. Hoffman wrote:

> Date: Thu, 24 Feb 2005 21:49:58 -0500
> From: Mark M. Hoffman <mhoffman@lightlink.com>
> Reply-To: Philadelphia Linux User's Group Discussion List
>     <plug@lists.phillylinux.org>
> To: Philadelphia Linux User's Group Discussion List
>     <plug@lists.phillylinux.org>
> Subject: Re: [PLUG] OSX "middleware"?
> 
> Hi:
>
> * William H. Magill <magill@mcgillsociety.org> [2005-02-24 13:46:23 -0500]:
>> On 24 Feb, 2005, at 09:26, Art Alexion wrote:
>>> Carlos Konstanski wrote:
>>>> Yes, gtkpod will get tunes on and off your iPod.  I will get that HFS
>>>> patch soon.  And you can always format the iPod as FAT32 if you wish,
>>>> which will circumvent all filesystem issues.  This is what Windows
>>>> (pardon my French) does to iPods.
>>>>
>>> Why does Apple's flagship product us a microsoft file system??
>>
>> The iPod isn't Apple's flagship product, only its most popular one --
>> there is a difference.
>>
>> The iPod uses an operating system purchased from a third party (if you
>> are interested, it is, or at least the first generation OS was, written
>> in a dialect of SNOBOL!).
>>
>> As was pointed out -- "embedded systems" are a whole different kettle
>> of fish.  Many things can be done because the product has a very
>> specific and restricted set of things which it is required to do.
>> Consequently there are many things which an "embedded system" can do to
>> maximize various aspects of its operation, from OS footprint to FS
>> optimization ... and, even with today's "huge" chips and such, "small"
>> is still the name of the game for "embedded systems," simply because
>> "bigger" directly translates to "more expensive" at the bottom line.
>
> Small isn't always the last consideration though.  FAT can be a very
> bad choice of filesystem for a compact-flash or EEPROM type device.
> The problem is that the FAT filesystem writes certain parts of the
> device more often than others, which can cause the device to wear out
> prematurely.  There are F/OSS filesystems that support "wear leveling",
> [1] so you may wonder why you never see a digital camera using those
> instead... well, that would force the Windows users to install a new
> filesystem driver.
>
> I.e. (again) a worse choice wins based on market-share.
>
> [1] http://www.linuxjournal.com/article/4678
>
> Regards,
>
> -- 
> Mark M. Hoffman
> mhoffman@lightlink.com
>
> ___________________________________________________________________________
> Philadelphia Linux Users Group         --        http://www.phillylinux.org
> Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
> General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug
>
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug