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
Re: [PATCH] Posix file attribute support on VFAT
On Tue, 9 Aug 2005, Machida, Hiroyuki wrote: > Bodo Eggert wrote: > Please confirm my understanding. > You sugessted that symlink should not have ATTR_SYS, to prevent > some over 4KB files created in DOS/WIN to be treated as symlinks? NACK, files longer than 4KB should not be symlinks, and maybe (if you're paranoid enough) files without a magic header should not be symlinks, too. BTW: What about storing short symlinks (strlen(name)+strlen(symlink) < 200) in the filename as $name.modified_base64($symlink) and storing the split position in ctime? This would reduce the need for data blocks, which may be valuable on small devices. -- Keep your hands off strong drink. It can make you shoot at the tax collector and miss. -- R.A. Heinlein - 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
Bodo Eggert wrote: Hiroyuki Machida <[EMAIL PROTECTED]> wrote: For newly created and/or modified files/dirs, system can utilize full posix attributes, because memory resident inode storage can hold those. After umount-mount cycle, system may lose some attributes to preserve VFAT format. Inodes may be reclaimed, therefore you might also lose some attributes at runtime. For your users, that will look like a heisenbug. A similar bug has been reported for procfs. Is your implementation affected? Yes. Thank you, pointed it out. So I need to select 1) restric attribute even in mamory or 2) pinn inode in memory during mount (I think it's not good idea) I'll revise the patch with 1). - Special file To distinguish special files, look if this fat dir entry has ATTR_SYS, first. If it has ATTR_SYS, then check 1st. LSB bit in ctime_cs, refered 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 spcial file detection mothod 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. You can add additional magic, e.g.: nodes must be empty, except for symlinks which must be not larger than 4KB (current PATH_MAX?). This will get rid of io.sys, logo.sys etc.\. If you want to be really sure, prepend a magic code to the on-disk representation of symlinks. Please confirm my understanding. You sugessted that symlink should not have ATTR_SYS, to prevent some over 4KB files created in DOS/WIN to be treated as symlinks? -- Hiroyuki Machida[EMAIL PROTECTED] SSW Dept. HENC, Sony Corp. - 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
Hiroyuki Machida <[EMAIL PROTECTED]> wrote: > For newly created and/or modified files/dirs, system can utilize > full posix attributes, because memory resident inode storage can > hold those. After umount-mount cycle, system may lose some > attributes to preserve VFAT format. Inodes may be reclaimed, therefore you might also lose some attributes at runtime. For your users, that will look like a heisenbug. A similar bug has been reported for procfs. Is your implementation affected? > - Special file > To distinguish special files, look if this fat dir entry > has ATTR_SYS, first. If it has ATTR_SYS, then check > 1st. LSB bit in ctime_cs, refered 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 spcial file detection mothod 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. You can add additional magic, e.g.: nodes must be empty, except for symlinks which must be not larger than 4KB (current PATH_MAX?). This will get rid of io.sys, logo.sys etc.\. If you want to be really sure, prepend a magic code to the on-disk representation of symlinks. -- Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF verbreiteten Lügen zu sabotieren. - 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
Ogawa-san and FAT developpers, Here is a patch to enable posix file attribute mapping to VFAT attributes, with restrictions. Main purpose of this patch is to build root file system with VFAT for small embedded 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. Thanks, Hiroyuki Machida --- * vfat-posix_attr.patch: fs/fat/file.c| 10 + fs/fat/inode.c | 27 +++ fs/vfat/namei.c | 291 ++ include/linux/msdos_fs.h | 320 +++ 4 files changed, 646 insertions(+), 2 deletions(-) Signed-off-by: Hiroyuki Machida <[EMAIL PROTECTED]> This patch enables "posix_attr" option described as following; "posix_attr" mapping support on VFAT. - Descriptions The option "posix_attr" enables attribute mapping from POSIX special files and permission modes/attributes to VFAT attributes and creation time fields. On memory resident inode storage holds full posix attributes, however in media side, VFAT can't have enough room to store all attributes. So attribute mapping taken by this option is designed to be minimal. For newly created and/or modified files/dirs, system can utilize full posix attributes, because memory resident inode storage can hold those. After umount-mount cycle, system may lose some attributes to preserve VFAT format. This mapping method has many restrictions, however it's very handy to build root file system with FAT for small embedded device where inter-operation with PC is needed. - Features Following attributes/modes are supported with this option in VFAT media side. However, on memory resident inode storage holds full posix attributes. That means, for newly created and/or modified files/dirs, system can utilize full posix attributes. After umount-mount cycle, system can just keep following attributes/modes. - FileType File type is held in 3MSB bits in ctime_cs. This enables support following special files. symbolic link, block device node, char device node, fifo, socket Regular files 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: 2nd LSB bit in ctime_cs 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 -1 as last resort. - Permission for Group/Other (rwx): 3rd-5th LSB bit in ctime_cs Those modes will be kept in ctime_cs. Also permission modes for "others" will be same as "group", due to lack of fields. - 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 attribute 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 "poisx_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. If it has ATTR_SYS, then check 1st. LSB bit in ctime_cs, refered 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 spcial file detection mothod 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. - FAT DIR entry fields description - ctime_cs 8bit byte 7 6 5 4 3 2 1 0 |===| | | | | | TYPE | | | | +- special file flag (vaild if ATTR_SYS) | | | +--- User/Group ID(owner) | | +- !group X | +--- !group W +- !group R special file flag Indicate this entry has posix attribut mapping. This field is vaild for fat dir entry, which have ATTR
