Re: [PATCH] Posix file attribute support on VFAT (take #2)
Hi! > > Unfortunately, it makes sense. If you have compact flash card, you > > really want to have VFAT there, so that it is a) compatible with > > windows and b) so that you don't kill the hardware. > > VFAT is plenty good at killing hardware. It's a terrible filesystem for > flash cards (if they don't do their own wear leveling properly). Most Well, they actually do test those cards with VFAT. Rumors are, they have some VFAT specific hacks in flash card firmware. -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Posix file attribute support on VFAT (take #2)
On Mon, Aug 22, 2005 at 01:46:29PM +0200, Pavel Machek wrote: > Unfortunately, it makes sense. If you have compact flash card, you > really want to have VFAT there, so that it is a) compatible with > windows and b) so that you don't kill the hardware. VFAT is plenty good at killing hardware. It's a terrible filesystem for flash cards (if they don't do their own wear leveling properly). Most of the linux filesystems may not be any better but they are also no worse. Windows compatibility is completely irrelevant if the card is being used as your root filesystem since any extensions you make to vfat wouldn't be understood by windows anyhow, so at best it makes a mess of it. > I guess being able to use CF card for root filesystem is usefull, > too I run ext3 on CF and so far, no problems. I run with noatime and try to avoid writing in general as much as possible. VFAT would be crap since, well, I run linux on the system. Len Sorensen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Posix file attribute support on VFAT (take #2)
On 8/22/05, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > > This is a take 2 of posix file attribute support on VFAT.
> >
> > Sorry, but this is far too scary. Please just use one of the sane
> > filesystems linux supports.
>
> Unfortunately, it makes sense. If you have compact flash card, you
> really want to have VFAT there, so that it is a) compatible with
> windows and b) so that you don't kill the hardware.
Why not using fuse in a initramfs?
Why not doing this with fuse? Write a filesystem that will use the
base fat file system (or any other stupid file system) but using a
database (BSD) or a file for non existent field. This new layer will
implement:
o mapping between true name and short name
o links (soft and emulated hard)
o permissions (and special files)
This solution is more general and can apply to all the stupid filesystems.
In the initramfs we need only to put:
o fuse module
o our fuse filesystem statically linked or again klibc.
Moreover this doesn't add more fat (fat because previous solution is
really ugly) to the kernel and will implement an universal umsdos.
I believe a shell program example will give you a better idea of my minds:
-
modprobe fuse
mount -t vfat /dev/hda1 /mnt
# fuse filesystem use the old /mnt
# It do a chdir in /mnt (base) before the mount was efective
mount -t fuse_extenddumbfilesystem none /mnt -o base=/mnt
# chroot
chroot /mnt
---
But some could object that fuse like a support of write shared memory
mmaped segment, but it is not different than nfs root!
Slowness is not a valid argument because fat and other file system are
not really suitable for unix computing...
I join as an attachment (I know, it is not really good), my 1c simple
implementation of such filesystem. This program do only the fuse bind
mount nothing else but if somebody want to go further...
> I guess being able to use CF card for root filesystem is usefull,
> too
>
>Pavel
> --
> if you have sharp zaurus hardware you don't need... you know my address
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
/*
FUSE: Filesystem in Userspace
Copyright (C) 2001-2005 Miklos Szeredi <[EMAIL PROTECTED]>
This program can be distributed under the terms of the GNU GPL.
See the file COPYING.
*/
//#include
//#ifdef linux
/* For pread()/pwrite() */
#define _XOPEN_SOURCE 500
#define FUSE_USE_VERSION 22
#define _FILE_OFFSET_BITS 64
//#endif
#include
#include
#include
#include
#include
#include
#include
#include
#ifdef HAVE_SETXATTR
#include
#endif
/*
* remove the absolute path part
*/
static char *local=".";
static inline const char *rel(const char *path)
{
if(strcmp(path,"/")==0)
return local;
else
return (path+1);
}
static int xmp_getattr(const char *path, struct stat *stbuf)
{
int res;
res = lstat(rel(path), stbuf);
if(res == -1)
return -errno;
return 0;
}
static int xmp_readlink(const char *path, char *buf, size_t size)
{
int res;
res = readlink(rel(path), buf, size - 1);
if(res == -1)
return -errno;
buf[res] = '\0';
return 0;
}
static int xmp_readdir(const char *path, void *buf, fuse_fill_dir_t filler,
off_t offset, struct fuse_file_info *fi)
{
DIR *dp;
struct dirent *de;
(void) offset;
(void) fi;
dp = opendir(rel(path));
if(dp == NULL)
return -errno;
while((de = readdir(dp)) != NULL) {
struct stat st;
memset(&st, 0, sizeof(st));
st.st_ino = de->d_ino;
st.st_mode = de->d_type << 12;
if (filler(buf, de->d_name, &st, 0))
break;
}
closedir(dp);
return 0;
}
static int xmp_mknod(const char *path, mode_t mode, dev_t rdev)
{
int res;
res = mknod(rel(path), mode, rdev);
if(res == -1)
return -errno;
return 0;
}
static int xmp_mkdir(const char *path, mode_t mode)
{
int res;
res = mkdir(rel(path), mode);
if(res == -1)
return -errno;
return 0;
}
static int xmp_unlink(const char *path)
{
int res;
res = unlink(rel(path));
if(res == -1)
return -errno;
return 0;
}
static int xmp_rmdir(const char *path)
{
int res;
res = rmdir(rel(path));
if(res == -1)
return -errno;
return 0;
}
static int xmp_symlink(const char *from, const char *to)
{
int res;
res = symlink(rel(from), to);
if(res == -1)
return -errno;
return 0;
}
static int xmp_rename(const char *from, const char *to)
{
int res;
res = rename(rel(from), rel(to));
if(res == -1)
return -errno;
return 0;
}
static int xmp_link(const char *from, const char *to)
{
int res;
res = link(rel(from), rel
Re: [PATCH] Posix file attribute support on VFAT (take #2)
Hi! > > This is a take 2 of posix file attribute support on VFAT. > > Sorry, but this is far too scary. Please just use one of the sane > filesystems linux supports. Unfortunately, it makes sense. If you have compact flash card, you really want to have VFAT there, so that it is a) compatible with windows and b) so that you don't kill the hardware. I guess being able to use CF card for root filesystem is usefull, too Pavel -- if you have sharp zaurus hardware you don't need... you know my address - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Posix file attribute support on VFAT (take #2)
On Thu, Aug 18, 2005 at 07:52:23PM +0900, Hiroyuki Machida wrote: > Christoph Hellwig wrote: > >On Wed, Aug 17, 2005 at 04:07:03AM +0900, Machida, Hiroyuki wrote: > >>This is a take 2 of posix file attribute support on VFAT. > > > > > >Sorry, but this is far too scary. Please just use one of the sane > >filesystems linux supports. > > > > I would say that purpose of the feature is having ability to > build root fs for small embedded device, not support full posix > attributes top of VFAT. I think the situation is like uclinux, > which has no MMU support and many restriction, however it's still > very helpful for small embedded device. This doesn't seem so different from umsdos to me -- which was only removed from the kernel because it was unmaintained. It might have its place. However, I'd guess you'd need to demonstrate that someone is actually going to use and maintain this feature before it would be considered for inclusion in the kernel. -- Joseph Fannin [EMAIL PROTECTED] "Bull in pure form is rare; there is usually some contamination by data." -- William Graves Perry Jr. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Posix file attribute support on VFAT (take #2)
I'm trying to explain background Christoph Hellwig wrote: On Wed, Aug 17, 2005 at 04:07:03AM +0900, Machida, Hiroyuki wrote: This is a take 2 of posix file attribute support on VFAT. Sorry, but this is far too scary. Please just use one of the sane filesystems linux supports. I would say that purpose of the feature is having ability to build root fs for small embedded device, not support full posix attributes top of VFAT. I think the situation is like uclinux, which has no MMU support and many restriction, however it's still very helpful for small embedded device. To reduce resource consumption, developers for embedded system would like to select one file system type to be used, if possible. And in most case, FAT is required for data exchange. E.g. memory/storage card or USB client. So adding small feature to FAT could have ability to build root fs, it's very helpful. It's not required to support full attributes. What do you think ? Thanks, Hiroyuki Machida - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Posix file attribute support on VFAT (take #2)
On Wed, Aug 17, 2005 at 04:07:03AM +0900, Machida, Hiroyuki wrote: > > This is a take 2 of posix file attribute support on VFAT. Sorry, but this is far too scary. Please just use one of the sane filesystems linux supports. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Posix file attribute support on VFAT (take #2)
This is a take 2 of posix file attribute support on VFAT. I made a couple of changes from previous revision, according feedbacks on LKML. - clean up - restrict file attribute operations to prevent attribute lose at runtime. - added condition checking to special files like device files and symlink. I did not yet implement short symlik optimization, sugessted at <[EMAIL PROTECTED]> from [EMAIL PROTECTED] Main purpose of this patch is to build root file system with VFAT for smallembedded device. FAT is widely used for embedded device to exchange data, and also small embedded device has resource limitation. So it's very handy that VFAT has capability to built root fs, even that has restrictions. Details are described within a patch. I think this feature still needs improvemnts, however it is very helpful for most embedded developpers. This patch is against 2.6.12 kernel. -- Hiroyuki Machida[EMAIL PROTECTED] SSW Dept. HENC, Sony Corp. This patch enables "posix_attr" option described as following; vfat posix attr option "posix_attr" Mon Aug 15 21:29:54 JST 2005 * FEATURES Following attributes/modes are supported in posix attributea mapping in VFAT. - FileType This supports following special files and it's attributes; symbolic link, block device node, char device node, fifo, socket Regular files/dirs also may have POSIX attributes. - DeviceFile Major and minor number would be held at ctime and both values are limited to 255. - Owner's User ID/Group ID This can be used to distinguish root and others, because this has just one bit width. Value of UID/GID for non-root user will be taken from uid/gid option on mounting. If nothing is specified, system uses (u16)-1 as last resort. That means change-uid may affect on gid. - Permission for Group/Other (rwx) Those modes will be kept in ctime_cs. Also permission modes for "others" will be same as "group", due to lack of fields. That means set-group-mode may affect on other-mode. On the other hand, set-other-mode has no affect to group-mode. - Permission for Owner (rwx) These modes will be mapped to FAT attributes. Just same as mapping under VFAT. - Others no sticky, setgid nor setuid bits are not supported. * ALGORITHM FOR MAPPING DECISION - Regular file/dir To distinguish regular files/dirs, look if this fat dir entry doesn't have ATTR_SYS, first. If it doesn't have ATTR_SYS, then check if TYPE field (MSB 3bits) in ctime_cs is equal to 7. If so, this regular file/dir is created and/or modified under VFAT with "posix_attr". And posix attribute mapping can be take place. Otherwise, conventional VFAT attribute mapping is used. - Special file To distinguish special files, look if this fat dir entry has ATTR_SYS, first. Also we need to check it not to have ATT_EXT. If it has ATTR_SYS, then check 1st. LSB bit in ctime_cs, referred as "special file flag". If set, this file is created under VFAT with "posix_attr". Look up TYPE field to decide special file type. This special file detection method has some flaw to make potential confusion. E.g. some system file created under dos/win may be treated as special file. However in most case, user don't create system file under dos/win. To reduce possiblity of this confusion, system makes sure special files except symlink have size ZERO. For symlink, system checks it's size not to exceed page size and PATH_MAX. * FAT DIR ENTRY FIELDS - ctime_cs 8bit byte 7 6 5 4 3 2 1 0 |===| | | | | | TYPE | | | | +- special file flag (valid if ATTR_SYS) | | | +--- User/Group ID(root or others) | | +- !group X | +--- !group W +- !group R special file flag Indicate this entry has posix attribute mapping. This field is valid for fat dir entry, which have ATTR_SYS. special file TYPE val type on VFS(val)Description 0 (place folder for backward compat) 1 DT_LNK (10) symbolic link 2 DT_BLK (6) block dev 3 DT_CHR (4) char dev 4 DT_FIFO (1) fifo 5 DT_SOCK (12)socket 7*) (reserved for DT_REG/DT_DIR) *)Value 7 is reserved for regular file/dir (DT
