[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
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 2005年2月24日, Mark M. Hoffman wrote:
> Date: 2005年2月24日 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