Re: ffsv2 extattr support
Hi, my development snapshot of xorriso is now able to record and restore extattr on NetBSD. Main work was to make it tolerate the error ENOENT that is thrown by extattr_list_link(2) if the filesystem does not support extattr. Else it is much like FreeBSD. I will have to compare the behavior of both in more detail. I think getextattr(1) needs mending. See at end of this mail: getextattr(1) has problems --- One peculiarity shows up: extattr_get_link(2) et.al. return the attribute content with a trailing 0-byte. This 0-byte seems to be a bug-or-feature of setextattr(1). I overwrote an extattr in the ISO filesystem by xorriso means without a trailing 0-byte. Then i extracted it into the FFSv1 filesystem and recorded it by xorriso again. No 0-byte appeared. So the extattr_*(2) functions and xorriso are not the ones who created those 0s. Neither FreeBSD nor Linux show trailing 0-bytes with their cleartext extattr/xattr. I care for portability of attributes in namespace user. So it would be interesting to know whether the convention on NetBSD is to have a 0-byte at the end of attribute content. extattr(9) specifies nul-terminated character string for names. But content is usually regarded as binary data, governed by the length value and not by a terminating character. If the 0-byte is convention, then i would consider to strip it when recording and to add it when restoring. But that would be feasible only if namespace user is reserved for C character strings rather than byte arrays. --- Demo with current development snapshot http://scdbackup.webframe.org/xorriso-1.3.7.tar.gz MD5 117954392e6359d5be8a2fcc0a965447 Version timestamp : 2014.06.20.065402 (in xorriso/xorriso_timestamp.h or in output of xorriso -version) # Create files with extattr in suitable filesystem /mnt/ffs1 echo x /mnt/ffs1/x echo y /mnt/ffs1/y setextattr user bla xbla /mnt/ffs1/x setextattr user bla YYYbla /mnt/ffs1/y getextattr user bla /mnt/ffs1/x getextattr user bla /mnt/ffs1/y # yields: # /mnt/ffs1/x xbla # /mnt/ffs1/y YYYbla # Record in an ISO 9660 filesystem image (/tmp/extattr_test.iso), # or in disk device (/dev/wd2f), or on optical medium (/dev/rcd0d). # I avoid the directory /mnt/ffs1/.attributes which is not readable # for the common user. drive=/tmp/extattr_test.iso xorriso \ -for_backup \ -outdev $drive \ -blank as_needed \ -add /mnt/ffs1/* -- # Inspect ISO xorriso \ -for_backup \ -indev $drive \ -getfattr_r / -- # yields: # # file: mnt/ffs1/x # user.bla=xbla\000 # # file: mnt/ffs1/y # user.bla=YYYbla\000 # Restore /mnt/ffs1 from ISO into a new directory /mnt/ffs1/xorriso_extracted xorriso \ -for_backup \ -indev $drive \ -osirrox on \ -extract /mnt/ffs1 /mnt/ffs1/xorriso_extracted # Inspect in FFSv1 getextattr user bla /mnt/ffs1/xorriso_extracted/* # yields: # /mnt/ffs1/xorriso_extracted/x xbla # /mnt/ffs1/xorriso_extracted/y YYYbla getextattr(1) has problems: echo a /mnt/ffs1/a setextattr user bla /mnt/ffs1/a getextattr user bla /mnt/ffs1/* # yields: # /mnt/ffs1/a # /mnt/ffs1/x xblaAAA # getextattr: /mnt/ffs1/xorriso_extracted: failed: No message available # Note that the content of ./x is shown mangled and ./y is not listed. getextattr user bla /mnt/ffs1/x # yields: # /mnt/ffs1/x xbla getextattr user bla /mnt/ffs1/y # yields: # /mnt/ffs1/y YYYbla # Note that all three files were treated with setextattr(1) # and not created by xorriso. I am not to blame (TM). The problem with the mangled values is in /usr/src/usr.bin/extattr/extattr.c In line 370 it asks for the size of the attribute if (flag_nofollow) error = extattr_get_link(argv[arg_counter], attrnamespace, attrname, NULL, 0); else error = extattr_get_file(argv[arg_counter], attrnamespace, attrname, NULL, 0); if (error 0) break; submits it to the local function mkbuf(buf, buflen, error); which leaves buflen unchanged if the new demand error is smaller than the previous one. In line 409 it uses buflen as the length of the value fwrite(buf, buflen, 1, stdout); The small patch would be - fwrite(buf, buflen, 1, stdout); + fwrite(buf, error, 1, stdout);
Re: ffsv2 extattr support
Hi, one point for man 1 getextattr and against me: The abort on the first file without attributes could be a feature, if one is willing to count a non-existing requested attribute as an error. Option -f overrides this early abort. So my change proposal about line 376 is not needed. (It was not complete anyway.) - One could discuss whether a missing attribute is really an error. Linux, which has more experience with using xattr, only issues warnings but does not indicate error: $ getfattr -n user.uerg x x x: user.uerg: No such attribute y: user.uerg: No such attribute $ echo $? 0 In contrast to a missing file: $ getfattr -n user.uerg xyz x getfattr: xyz: No such file or directory x: user.uerg: No such attribute $ echo $? 1 Have a nice day :) Thomas
Re: ffsv2 extattr support
On Fri, Jun 20, 2014 at 9:11 AM, Thomas Schmitt scdbac...@gmx.net wrote: One peculiarity shows up: extattr_get_link(2) et.al. return the attribute content with a trailing 0-byte. This 0-byte seems to be a bug-or-feature of setextattr(1). I overwrote an extattr in the ISO filesystem by xorriso means without a trailing 0-byte. Then i extracted it into the FFSv1 filesystem and recorded it by xorriso again. No 0-byte appeared. So the extattr_*(2) functions and xorriso are not the ones who created those 0s. Neither FreeBSD nor Linux show trailing 0-bytes with their cleartext extattr/xattr. I care for portability of attributes in namespace user. So it would be interesting to know whether the convention on NetBSD is to have a 0-byte at the end of attribute content. extattr(9) specifies nul-terminated character string for names. But content is usually regarded as binary data, governed by the length value and not by a terminating character. If the 0-byte is convention, then i would consider to strip it when recording and to add it when restoring. But that would be feasible only if namespace user is reserved for C character strings rather than byte arrays. This looks like a bug to me, attribute values need to be binary. I have some tests which run on Linux and FreeBSD but I haven't run them on NetBSD yet due to my current systems not having support (would be nice if tmpfs had support). Justin
Re: ffsv2 extattr support
Hi, me: This 0-byte seems to be a bug-or-feature of setextattr(1). Justin Cormack: This looks like a bug to me, attribute values need to be binary. Probable cause is in getextattr.c line 314: val_len = strlen(argv[0]) + 1; with effect in line 338: error = extattr_set_file(argv[arg_counter], attrnamespace, attrname, buf, val_len + flag_null); I would do - val_len = strlen(argv[0]) + 1; - mkbuf(buf, buflen, val_len); + val_len = strlen(argv[0]); + mkbuf(buf, buflen, val_len + 1); At least this helps here: $ cd /usr/src/usr.bin/extattr $ ln -s getextattr setextattr $ echo b /mnt/ffs1/b $ ./setextattr user bla B /mnt/ffs1/b $ xorriso -for_backup -outdev stdio:/dev/null -map /mnt/ffs1/b /b -getfattr /b -- -rollback_end ... user.bla=B No zeros. No ambiguity. No visible problems with ./getextattr: $ ./getextattr -f user bla /mnt/ffs1/* /mnt/ffs1/a /mnt/ffs1/b B /mnt/ffs1/x xbla getextattr: /mnt/ffs1/xorriso_extracted: failed: No message available /mnt/ffs1/y YYYbla Have a nice day :) Thomas
Re: ffsv2 extattr support
On Fri, Jun 20, 2014 at 12:13:00PM +0200, Thomas Schmitt wrote: Probable cause is in getextattr.c line 314: val_len = strlen(argv[0]) + 1; with effect in line 338: error = extattr_set_file(argv[arg_counter], attrnamespace, attrname, buf, val_len + flag_null); IIRC, we must store a trailing 0 because of an oddity in the FreeBSD API. Perhaps it should be stripped when reading the attribute? How is it done in FreeBSD sources? -- Emmanuel Dreyfus m...@netbsd.org
Re: ffsv2 extattr support
Hi,
Emmanuel Dreyfus:
IIRC, we must store a trailing 0 because of an oddity in the FreeBSD API.
It causes a slight but possibly painful incompatibility to other
systems. An appended 0 might have a meaning in some special case.
So one should not flood the user namespace with them.
What API/ABI might be affected ?
I believe to see that the current way in getextattr.c is wrong
if option -n sets variable flag_null to 1.
Pity there is no valgrind to prove that this is bad memory usage:
mkbuf(buf, buflen, val_len);
...
error = extattr_set_file(argv[arg_counter],
attrnamespace, attrname, buf,
val_len + flag_null);
In any case, the result proves that flag_null was indeed 1:
$ echo c /mnt/ffs1/c
$ setextattr -n user bla c_with_n /mnt/ffs1/c
$ getextattr -s user bla /mnt/ffs1/c
/mnt/ffs1/c c_with_n\000\000
How is it done in FreeBSD sources?
Without unconditionally adding 1 to strlen().
http://svnweb.freebsd.org/base/head/usr.sbin/extattr/rmextattr.c?revision=248995view=markup#l186
if (what == EASET) {
mkbuf(buf, buflen, strlen(argv[0]) + 1);
strcpy(buf, argv[0]);
argc--; argv++;
}
Line 205:
len = strlen(buf) + flag_null;
Line 210:
ret = extattr_set_file(argv[arg_counter],
attrnamespace, attrname, buf, len);
Have a nice day :)
Thomas
Re: ffsv2 extattr support
On Fri, Jun 20, 2014 at 12:13:00PM +0200, Thomas Schmitt wrote: I would do - val_len = strlen(argv[0]) + 1; - mkbuf(buf, buflen, val_len); + val_len = strlen(argv[0]); + mkbuf(buf, buflen, val_len + 1); I committed this. -- Emmanuel Dreyfus m...@netbsd.org
Re: ffsv2 extattr support
Hi, - val_len = strlen(argv[0]) + 1; - mkbuf(buf, buflen, val_len); + val_len = strlen(argv[0]); + mkbuf(buf, buflen, val_len + 1); Emmanuel Dreyfus: I committed this. On the risk to be obtrusive, how about in line 409: - fwrite(buf, buflen, 1, stdout); + fwrite(buf, error, 1, stdout); buflen is really the wrong variable. error is only a misnomer. The negative effect is that long attribute content shows up in the content of the next file with shorter content $ getextattr user bla /mnt/ffs1/[ax] /mnt/ffs1/a /mnt/ffs1/x xblaAAA The code path which does strvisx(visbuf, buf, error, flag_vis); shows correct length: $ getextattr -s user bla /mnt/ffs1/[ax] /mnt/ffs1/a \000 /mnt/ffs1/x xbla\000 Have a nice day :) Thomas
Re: ffsv2 extattr support
On Fri, Jun 20, 2014 at 05:13:25PM +0200, Thomas Schmitt wrote: strvisx(visbuf, buf, error, flag_vis); Committed. -- Emmanuel Dreyfus m...@netbsd.org
Re: ffsv2 extattr support
Hi,
my NetBSD 6.99.44 seems to be complete now. From daily build ISO+FTP
and then from cvs checkout -A of yesterday. Guided by
http://www.netbsd.org/docs/guide/en/chap-fetch.html#chap-fetch-cvs
http://www.netbsd.org/docs/guide/en/chap-updating.html
But i had no success with getting an FFSv1 filesystem with extattr
support. In part it seems to believe to be able, but the real
action does not work.
---
netbsdcur# disklabel -i -I wd1
partitionN
Label name [fictitious]: ffs1test
partitionW
Label disk [n]?y
Label written
partitionE
# /dev/rwd1d:
type: ESDI
disk: QEMU HARDDISK
label: ffs1test
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 260
total sectors: 262144
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # microseconds
track-to-track seek: 0 # microseconds
drivedata: 0
4 partitions:
#sizeoffset fstype [fsize bsize cpg/sgs]
a:262144 0 4.2BSD 0 0 0 # (Cyl. 0 -260*)
d:262144 0 unused 0 0# (Cyl. 0 -260*)
partitionQ
--
netbsdcur# newfs -O 1 /dev/rwd1a
/dev/rwd1a: 128.0MB (262144 sectors) block size 8192, fragment size 1024
using 4 cylinder groups of 32.00MB, 4096 blks, 7936 inodes.
super-block backups (for fsck_ffs -b #) at:
32, 65568, 131104, 196640,
--
netbsdcur# mkdir /mnt/ffs1
netbsdcur# mount /dev/wd1a /mnt/ffs1
netbsdcur# cd /mnt/ffs1
netbsdcur# mkdir -p .attribute/system .attribute/user
netbsdcur# cd ..
netbsdcur# umount /mnt/ffs1
netbsdcur# mount -o extattr /dev/wd1a /mnt/ffs1
mount_ffs: /dev/wd1a on /mnt/ffs1: Operation not supported
netbsdcur# mount
/dev/wd0a on / type ffs (local)
...
/dev/wd1a on /mnt/ffs1 type ffs (extattr, local)
--
netbsdcur# echo xyz /mnt/ffs1/x
netbsdcur# getextattr system bla /mnt/ffs1/x
getextattr: /mnt/ffs1/x: failed: Operation not supported
netbsdcur# setextattr user bla blablabla /mnt/ffs1/x
setextattr: /mnt/ffs1/x: failed: Operation not supported
netbsdcur# getextattr system bla /mnt/ffs1/x
getextattr: /mnt/ffs1/x: failed: Operation not supported
--
But statvfs(2) as well as mount(8) indicate that extattr is enabled:
int main(int argc, char **argv)
{
int ret;
struct statvfs buf;
ret = statvfs(/mnt/ffs1/x, buf);
if (ret == 0)
printf(MNT_EXTATTR in statvfs.f_flag : %d\n, buf.f_flag MNT_EXTATTR);
exit(!!ret);
}
yields:
MNT_EXTATTR in statvfs.f_flag : 16777216
---
Have a nice day :)
Thomas
Re: ffsv2 extattr support
On Thu, Jun 19, 2014 at 03:28:41PM +0200, Thomas Schmitt wrote: But i had no success with getting an FFSv1 filesystem with extattr support. In part it seems to believe to be able, but the real action does not work. (...) netbsdcur# mount -o extattr /dev/wd1a /mnt/ffs1 mount_ffs: /dev/wd1a on /mnt/ffs1: Operation not supported Oh yes, you need to rebuild a kernel with the following options: options UFS_EXTATTR options UFS_EXTATTR_AUTOSTART options UFS_EXTATTR_AUTOCREATE=1024 -- Emmanuel Dreyfus m...@netbsd.org
Re: ffsv2 extattr support
Hi, you need to rebuild a kernel with the following options: options UFS_EXTATTR ... Now it seems to work. netbsdcur# getextattr user bla /mnt/ffs1/x /mnt/ffs1/x blablabla I will report as soon as i can offer backup for NetBSD extattr. Have a nice day :) Thomas
Re: ffsv2 extattr support
Hi, Mark Davies: back in Jan 2012 there was some discussion about ffsv2 extattr support initiated by Manuel Bouyer. What is the current state of that? Is there anything in Current? Emmanuel Dreyfus: AFAIK extattr are only availabe in FFSv1, and userland tools sur as dump/restore/tar lack support for it, which means we cannot backup them. In principle, my xorriso would be able to record and to restore extattr and ACLs in ISO 9660 filesystems as SUSP entries. Currently it is lacking the NetBSD functions to read and write them from and to other filesystems. I see there is a man page for extattr_get_file(2) et.al. A FreeBSD implementation of the extattr interface is already existing in libisofs. For a test i hacked the selection of conditional code and it does at least compile on NetBSD. So i would next need some instructions how to create a NetBSD filesystem with extattr in order to verify that xorriso properly records the attributes in its ISO 9660 filesystems (as SUSP entries). For restoring with extattr, one would have to employ xorriso or implement AAIP in sys/fs/cd9660: http://libburnia-project.org/wiki/AAIP Do i get it right that there is no ACL support in NetBSD ? (At least there is no man page for acl_get_file().) Have a nice day :) Thomas
Re: ffsv2 extattr support
Thomas Schmitt scdbac...@gmx.net wrote: So i would next need some instructions how to create a NetBSD filesystem with extattr i format as FFSv1 mount mkdir -p .attribute/system .attribute/user, umount mount -o extattr -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: ffsv2 extattr support
Hi, Emmanuel Dreyfus : format as FFSv1 That would be newfs -O 1 ? After disklabel ? (I will start with an empty qemu disk.) Up to now, it was always the installation software which formatted my NetBSD disks. Let's hope the manual will guide me through this. ... mount -o extattr I will try to achieve this when i got my new 6.99.44 installation complete. Meanwhile i have tested the FreeBSD-specific code with NetBSD on a default filesystem (FFSv2 ?). It works so far, but the reaction on non-extattr filesystems is too harsh. I'll have to better distinguish filesystems without extattr support from read problems with individual files. Is there a global indication (in userspace) whether a mounted filesystem supports extattr ? statvfs(2) seems not to tell. Have a nice day :) Thomas
Re: ffsv2 extattr support
On Wed, Jun 18, 2014 at 04:50:11PM +0200, Thomas Schmitt wrote: That would be newfs -O 1 ? After disklabel ? Yes. filesystem supports extattr ? statvfs(2) seems not to tell. Look for MNT_EXTATTR in struct statvfs's f_flag -- Emmanuel Dreyfus m...@netbsd.org
ffsv2 extattr support
Hi, back in Jan 2012 there was some discussion about ffsv2 extattr support initiated by Manuel Bouyer. What is the current state of that? Is there anything in Current? cheers mark
Re: ffsv2 extattr support
Mark Davies m...@ecs.vuw.ac.nz wrote: back in Jan 2012 there was some discussion about ffsv2 extattr support initiated by Manuel Bouyer. What is the current state of that? Is there anything in Current? AFAIK extattr are only availabe in FFSv1, and userland tools sur as dump/restore/tar lack support for it, which means we cannot backup them. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: updated patch Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
matthew green m...@eterna.com.au wrote: David Holland dholland-t...@netbsd.org wrote: On Mon, Jan 16, 2012 at 10:28:57PM +0100, Manuel Bouyer wrote: I consider lfs second-class citizen at this time and if forward compat if broken for the lfs module on the branch it's probably not a big deal). I don't consider that acceptable... I am in agreement with Manuel. Without going into argument on BSD LFS design issues, current code is way too far from being anywhere stable and reliable. It should not block any progress in other subsystems. irregardless of what LFS is or isn't, breaking it on the branch is not acceptable. you might not use it or trust it, but there are people who do -- the people who maintain it -- and the same argument applies equally to their work as to any other work. The point being is that such for a long time defective piece of code like LFS should not block other features and general progress, nor it should be preserved under any cost (like it was done in notorious SA case, when today the code is still broken, unmaintained and hardly has any real users). There is also another point - user experience, which perhaps deserves a wider discussion, but not on tech-kern. .. more generally on this issue: i don't think it matters if netbsd-6 and -current end up having non-trivially different implementations of this code. what matters most is that we (a) release netbsd-6 soon and (b) keep it stable. if non-trivial changes are necessary for ffsv2 extattr support to be part of netbsd-6 then i think that those changes have missed the boat. if those changes can be kept localised, but not entirely clean, then netbsd-6 can still have the feature without the potential for disrupting the release. It is a valid point, I agree. On the other hand, Manuel's proposed patch is not that invasive. If there is a very clear benefit for having it in, I do not see why with some management it could not be adopted for netbsd-6. Think of PostgreSQL's patch-fiesta model. -- Mindaugas
Re: updated patch Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Fri, Jan 20, 2012 at 11:24:36AM +0100, Manuel Bouyer wrote: It is also moot. Provided that quota cleanup leaves me with enough time to merge and test (admittedly this is looking less and less likely), the ufs/lfs split will be in -6. (unlike the changes proposed in this thread, the ufs/lfs split has been in the works a long time and has been discussed with releng.) You've been talking about it for some time, but I've never seen details or patch about it on a public list. Perhaps it's been so long that you've forgotten? I couldn't find references to it in the releng mail archives either. That's because I've been talking with specific people about it. Anyhow, it's moot. The minimum necessary quota fixes are not, at this point, going to leave me time to get my lfs tree merged, let alone tested and running again, before the deadline. -- David A. Holland dholl...@netbsd.org
Re: updated patch Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Wed, Jan 25, 2012 at 11:29:32PM +, Mindaugas Rasiukevicius wrote: irregardless of what LFS is or isn't, breaking it on the branch is not acceptable. you might not use it or trust it, but there are people who do -- the people who maintain it -- and the same argument applies equally to their work as to any other work. The point being is that such for a long time defective piece of code like LFS should not block other features and general progress, nor it should be preserved under any cost (like it was done in notorious SA case, when today the code is still broken, unmaintained and hardly has any real users). There is also another point - user experience, which perhaps deserves a wider discussion, but not on tech-kern. Yes, part of the user experience is that we don't randomly break compatibility, particularly not on stable branches. And please define progress. If you want Red Hat, you know where to get it. Btw, I'm eagerly awaiting your review of the vfs-level quota patches. -- David A. Holland dholl...@netbsd.org
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Wed, Jan 18, 2012 at 08:41:21PM +, YAMAMOTO Takashi wrote: I'm not sure I'm understanding you. There is only one set of extended attributes blocks per vnode. let's call the entity buf_targ_t. the most of vnode * for buffer cache API would be changed to take buf_targ_t * instead of vnode *. callers would be changed from bread(vp, ...) to bread(vp-v_contents_buf_targ, ...). you might want to do bread(ip-i_xattr_buf_targ, ...) for extended attribute. you need two buf_targ_t for a vnode. (v_contents_buf_targ and i_xattr_buf_targ in the above example.) I like the idea. But that's a lot of work and is definitively not going to be in netbsd-6 -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: updated patch Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Thu, Jan 19, 2012 at 08:53:00AM +, David Holland wrote: It is also moot. Provided that quota cleanup leaves me with enough time to merge and test (admittedly this is looking less and less likely), the ufs/lfs split will be in -6. (unlike the changes proposed in this thread, the ufs/lfs split has been in the works a long time and has been discussed with releng.) You've been talking about it for some time, but I've never seen details or patch about it on a public list. I couldn't find references to it in the releng mail archives either. Anyway, I've asked core and releng about ffsv2 extattr; nothing will be commited before the branch; releng accepts to have different code in HEAD and netbsd-6. So I'll come back on the topic after netbsd-6 has been branched. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: updated patch Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Wed, Jan 18, 2012 at 08:34:01PM +0100, Manuel Bouyer wrote: So, who cares? I don't, but others may have a different view. It is also moot. Provided that quota cleanup leaves me with enough time to merge and test (admittedly this is looking less and less likely), the ufs/lfs split will be in -6. (unlike the changes proposed in this thread, the ufs/lfs split has been in the works a long time and has been discussed with releng.) -- David A. Holland dholl...@netbsd.org
Re: updated patch Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Wed, Jan 18, 2012 at 10:21:13AM +1100, matthew green wrote: I am in agreement with Manuel. Without going into argument on BSD LFS design issues, current code is way too far from being anywhere stable and reliable. It should not block any progress in other subsystems. irregardless of what LFS is or isn't, breaking it on the branch is not acceptable. you might not use it or trust it, but there are people who do -- the people who maintain it -- and the same argument applies equally to their work as to any other work. It's not breaking it on the branch, it introducing a backward compat problem with the lfs modules, for those who are using the lfs module (it's statically built into the kernel by default). I didn't feel it's a problem, but if it is it can fixed in a simple way: I could add the extra parameter to UFS_BALLOC() now, but not use it. this is for a change that i'm not even convinced is a good thing, Because you don't need extended attributes ? let alone deserves to invade changing the buffer cache so close to a release. more generally on this issue: i don't think it matters if netbsd-6 and -current end up having non-trivially different implementations of this code. what matters most is that we (a) release netbsd-6 soon and (b) keep it stable. if non-trivial changes are necessary for ffsv2 extattr support to be part of netbsd-6 then i think that those changes have missed the boat. if those changes can be kept localised, but not entirely clean, then netbsd-6 can still have the feature without the potential for disrupting the release. OK, so I guess we're back to using a B_ALTDATA in b_flags for netbsd-6. It has more potential to break things, but doesn't break backward compatibility for modules and so doesn't need changes to the buffer cache now. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: updated patch Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Wed, Jan 18, 2012 at 04:24:27PM +0100, Manuel Bouyer wrote: On Wed, Jan 18, 2012 at 10:03:02AM +0100, Manuel Bouyer wrote: It's not breaking it on the branch, it introducing a backward compat problem with the lfs modules, for those who are using the lfs module (it's statically built into the kernel by default). I didn't feel it's a problem, but if it is it can fixed in a simple way: I could add the extra parameter to UFS_BALLOC() now, but not use it. I'd add that the compat problem is what you run a new ffs module with an older lfs one. That would mean one has to update only some modules to run into it. So, leaving aside the question of whether this kind of code to support a new feature should go in so soon before a release -- it seems to me that the compatibility problem here is basically illusory. To see it, you'd have to be running the branch, using LFS as a module (which is not the default configuration), then update to a newer snapshot of the branch, then update only some of your modules, right? So, who cares? Thor
Re: updated patch Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Wed, Jan 18, 2012 at 02:27:30PM -0500, Thor Lancelot Simon wrote: On Wed, Jan 18, 2012 at 04:24:27PM +0100, Manuel Bouyer wrote: On Wed, Jan 18, 2012 at 10:03:02AM +0100, Manuel Bouyer wrote: It's not breaking it on the branch, it introducing a backward compat problem with the lfs modules, for those who are using the lfs module (it's statically built into the kernel by default). I didn't feel it's a problem, but if it is it can fixed in a simple way: I could add the extra parameter to UFS_BALLOC() now, but not use it. I'd add that the compat problem is what you run a new ffs module with an older lfs one. That would mean one has to update only some modules to run into it. So, leaving aside the question of whether this kind of code to support a new feature should go in so soon before a release -- it seems to me that the compatibility problem here is basically illusory. To see it, you'd have to be running the branch, using LFS as a module (which is not the default configuration), then update to a newer snapshot of the branch, then update only some of your modules, right? that's it for the changes in sys/ufs/ufs; the changes to struct buf affects much more modules. So, who cares? I don't, but others may have a different view. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
hi, On Mon, Jan 16, 2012 at 10:48:37PM +, YAMAMOTO Takashi wrote: hi, On Mon, Jan 16, 2012 at 10:00:05PM +, YAMAMOTO Takashi wrote: have you considered to separate the entity being cached from vnode? What would this buy us ? the data are intimely tied to the inode, cleaning the cache when a file is deleted or would be more difficult, isn't it ? it allows us to have more than one such entities for a vnode. it's what you want here, isn't it? I'm not sure I'm understanding you. There is only one set of extended attributes blocks per vnode. let's call the entity buf_targ_t. the most of vnode * for buffer cache API would be changed to take buf_targ_t * instead of vnode *. callers would be changed from bread(vp, ...) to bread(vp-v_contents_buf_targ, ...). you might want to do bread(ip-i_xattr_buf_targ, ...) for extended attribute. you need two buf_targ_t for a vnode. (v_contents_buf_targ and i_xattr_buf_targ in the above example.) YAMAMOTO Takashi -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Mon, Jan 16, 2012 at 10:48:37PM +, YAMAMOTO Takashi wrote: hi, On Mon, Jan 16, 2012 at 10:00:05PM +, YAMAMOTO Takashi wrote: have you considered to separate the entity being cached from vnode? What would this buy us ? the data are intimely tied to the inode, cleaning the cache when a file is deleted or would be more difficult, isn't it ? it allows us to have more than one such entities for a vnode. it's what you want here, isn't it? I'm not sure I'm understanding you. There is only one set of extended attributes blocks per vnode. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: updated patch Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Tue, Jan 17, 2012 at 01:21:33AM +, David Holland wrote: On Mon, Jan 16, 2012 at 10:28:57PM +0100, Manuel Bouyer wrote: I consider lfs second-class citizen at this time and if forward compat if broken for the lfs module on the branch it's probably not a big deal). I don't consider that acceptable... So, because of modules, we can't pullup new features to netbsd-6 ? -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: updated patch Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Tue, Jan 17, 2012 at 09:25:06PM +, David Holland wrote: On Tue, Jan 17, 2012 at 07:31:17PM +0100, Manuel Bouyer wrote: So, because of modules, we can't pullup new features to netbsd-6 ? How is this different from netbsd-5? Modules are not used by default on netbsd-5 AFAIK. On netbsd-6 options MUODULAR is in i386 GENERIC, but it seems filesystem modules are all compiled in by default. I'm not sure what other modules would be affected by a change to struct buf ... Releng has always as general policy refused changes that alter major internal APIs, regardless of module issues. AIUI, anyway. Some people have 3rd-party sources that would end up needing modifications and so forth. that's why I'd prefer to have the structure changes before the branch. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: updated patch Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
David Holland dholland-t...@netbsd.org wrote: On Mon, Jan 16, 2012 at 10:28:57PM +0100, Manuel Bouyer wrote: I consider lfs second-class citizen at this time and if forward compat if broken for the lfs module on the branch it's probably not a big deal). I don't consider that acceptable... I am in agreement with Manuel. Without going into argument on BSD LFS design issues, current code is way too far from being anywhere stable and reliable. It should not block any progress in other subsystems. -- Mindaugas
re: updated patch Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
David Holland dholland-t...@netbsd.org wrote: On Mon, Jan 16, 2012 at 10:28:57PM +0100, Manuel Bouyer wrote: I consider lfs second-class citizen at this time and if forward compat if broken for the lfs module on the branch it's probably not a big deal). I don't consider that acceptable... I am in agreement with Manuel. Without going into argument on BSD LFS design issues, current code is way too far from being anywhere stable and reliable. It should not block any progress in other subsystems. irregardless of what LFS is or isn't, breaking it on the branch is not acceptable. you might not use it or trust it, but there are people who do -- the people who maintain it -- and the same argument applies equally to their work as to any other work. this is for a change that i'm not even convinced is a good thing, let alone deserves to invade changing the buffer cache so close to a release. more generally on this issue: i don't think it matters if netbsd-6 and -current end up having non-trivially different implementations of this code. what matters most is that we (a) release netbsd-6 soon and (b) keep it stable. if non-trivial changes are necessary for ffsv2 extattr support to be part of netbsd-6 then i think that those changes have missed the boat. if those changes can be kept localised, but not entirely clean, then netbsd-6 can still have the feature without the potential for disrupting the release. .mrg.
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Sun, Jan 15, 2012 at 08:37:37PM +0100, Manuel Bouyer wrote: I don't think I'll be able to have this ready for netbsd-6, but I now know this requires 2 changes that will require a kernel version bump, so theses changes needs to go in before netbsd-6 is branched so that full extended attributes support can be pulled up later. The fisrt change is to the buffer cache. My first reaction is that I don't think it's a good idea to make major changes to the buffer cache at this stage in a release cycle. It's not exactly the most robust or stable code we have in the system. (Also, you're aware that it isn't used for file data blocks, right?) -- David A. Holland dholl...@netbsd.org
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Mon, Jan 16, 2012 at 04:37:57PM +, David Holland wrote: On Sun, Jan 15, 2012 at 08:37:37PM +0100, Manuel Bouyer wrote: I don't think I'll be able to have this ready for netbsd-6, but I now know this requires 2 changes that will require a kernel version bump, so theses changes needs to go in before netbsd-6 is branched so that full extended attributes support can be pulled up later. The fisrt change is to the buffer cache. My first reaction is that I don't think it's a good idea to make major changes to the buffer cache at this stage in a release cycle. It's not exactly the most robust or stable code we have in the system. On the other hand, changing the kernel ABI in the release branch is not a good idea either, given the state of the module subsystem ... I wouldn't call this a major change. The alternative way (adding a b_type member to struct buf) is even less intrusive; if the alternative (*2()) functions are not used it'll always be 0. (Also, you're aware that it isn't used for file data blocks, right?) It depends on what you call file data. Directory data blocks ends there AFAIK, as do symlink data blocks when the link's target doesn't fit in the inode. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Sun, 15 Jan 2012 15:21:40 -0500 (EST) Mouse mo...@rodents-montreal.org wrote: However, I think that constitutes a good implementation of a bad idea. This makes a file no longer a long list of octets; it becomes multiple long lists of octets. The Mac did this, with resource forks and data forks, and you may note OS X doesn't do it any longer. I suspect these will seem like a good idea for a while, until people start discovering all the things they break, or that break them, and realize that they didn't learn from history and thus had to repeat it. I didn't know that Apple dropped the idea, but I have always found the idea flaky myself (and sorry for the rant): - Applications may still implement and maintain metadata as they wish without the feature - Requires changes to support in OS, FS, and many file manipulation tools - No standard API for these, few, incompatible, restricted solutions/formats for archival - Security implications (scanning tools which aren't aware might skip hidden/extended data; if ACLs are eventually implemented and are using these, the implementation should not only support a system domain, but also use IDs rather than strings (or at least severely sanity-check a restricted string format)) - Inevitable eventual loss of the extended data, possibly because of backup procedures not aware of it, moving/copying/editing files with non-aware/third-party tools, etc (also consider editors that save to another file to then rename) - An administrative nightmare when tools such as find/locate/grep/diff won't disclose data that the admin might be looking for but is now in an extended attribute But this is only the opinion of a user, and I could keep the feature disabled on my systems, of course, so I don't necessarily object to optional support for it. -- Matt
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
This makes a file no longer a long list of octets; it becomes multiple long lists of octets. [...] [...] I have always found the idea flaky myself (and sorry for the rant): [...] Yeah. I think it's a very interesting direction to take filesystems. But this, interesting as it is, is research experimentation; we do not even nearly understand how to fit multi-fork (to adopt the MacOS term) files into a Unix paradigm (witness all the programs that we don't understand how to change for this), and investigating non-understood things is what research _is_. And I think the master tree for a (supposedly-)production OS is not the place to be carrying out research experiments, not even if another such OS is already doing it. But my opinions seem to correlate negatively with NetBSD's these days. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Mon, Jan 16, 2012 at 08:46:44PM +, David Holland wrote: On Mon, Jan 16, 2012 at 07:37:19PM +0100, Manuel Bouyer wrote: The fisrt change is to the buffer cache. My first reaction is that I don't think it's a good idea to make major changes to the buffer cache at this stage in a release cycle. It's not exactly the most robust or stable code we have in the system. On the other hand, changing the kernel ABI in the release branch is not a good idea either, given the state of the module subsystem ... Indeed. But that isn't really the question. The question is really whether we're past the date for brand-new feature proposals for netbsd-6... or at least ones that involve invasive changes. No, the question is whenever we commit the needed bits now for the feature to be pulled up without kernel API major change later, or if we accept a kernel API major change in the branch after netbsd-6-0 is branched. this won't ever be in netbsd-6 is not an option, I don't think we can wait for netbsd-7 for this. releng and/or core will need to rule on that but I don't think it's a good idea. The buffer cache code is ratty, poorly structured, and full of races that may or may not have visible consequences. Any change to it could turn out to be unexpectedly disruptive, and we don't at this point have time to clean up if the changes turn out to make a mess. (Especially since the person who'd likely have to do the cleanup, namely me, is already oversubscribed right up to the branch deadline on other stuff. Which, not to put too fine a point on it, includes sorting out a previous mess.) I wouldn't call this a major change. The alternative way (adding a b_type member to struct buf) is even less intrusive; if the alternative (*2()) functions are not used it'll always be 0. Changing the way the buffer cache is indexed is semantically intrusive even if it's not physically intrusive. While I think adding a type field to modify the block number is a good idea, for various reasons, it needs to be thought through, and it hasn't been yet and there isn't time to thrash it out fully before the branch deadline. Furthermore, there's the existing question of indexing by physical vs. virtual block numbers; that is not in any way a resolved issue and what you're proposing interacts directly with it, and this too needs to be thought through and there isn't time before the branch deadline. Yes, and I don't think we need to wait for theses questions to be sorted out to have ffs2 extended attributes. Even if the buffer cache code is rototilled later, I don't think extended attributes or the new type field will make it harder, and the code in HEAD and the netbsd-6 branch is allowed to diverge. Meanwhile, adding a whole set of extra functions instead of doing things properly with a massedit is highly undesirable; not only is it ugly but it leaves us unable to tidy the extra functions away in HEAD after branching, which is bad... unless we want to vastly complicate any pullup that goes near the buffer cache, which would be worse. A massive change to the buffer cache code won't be pulled up to netbsd-6 anyway (one of them being the mess it would cause for modules) so the code will not be the same in netbsd-6 and HEAD anyway. (Also, you're aware that it isn't used for file data blocks, right?) It depends on what you call file data. Directory data blocks ends there AFAIK, as do symlink data blocks when the link's target doesn't fit in the inode. Right. So, should extended attribute blocks go in the old buffer cache or should they be managed by uvm? This is another question we likely don't have time to address properly by the branch deadline. Definitively the buffer cache, so it's covered by the journal. This is metadata. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Mon, Jan 16, 2012 at 10:39:45PM +0100, Manuel Bouyer wrote: is branched. this won't ever be in netbsd-6 is not an option, I don't think we can wait for netbsd-7 for this. Why not? Martin
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
hi, Hello, I'm working on porting the FreeBSD FFSv2 extended attributes support. What we have right now only works for ffsv1 (it's a restriction in our sources but it could be extended to ffsv2), and uses a file hierarchy to store attributes. This has several issues, one being that it doesn't integrate with WAPBL and is very slow (glusterfs shows this very well). FFSv2 has native extended attributes support, in the form of 2 direct blocks reserved for this purpose in the on-disk inode. This was commented out in our kernel when FFSv2 support was imported. It should be possible to integrate this with WAPBL and handle it as other metadata, so it should be fast. fsck will also be able to check it. I don't think I'll be able to have this ready for netbsd-6, but I now know this requires 2 changes that will require a kernel version bump, so theses changes needs to go in before netbsd-6 is branched so that full extended attributes support can be pulled up later. The fisrt change is to the buffer cache. Right now the buffer cache is indexed by the couple vnode pointer, block number, block number being a block offset in the file being pointed to by vnode pointer. But we'll have 2 kinds of blocks: data blocks (what we have now) and extended attributes blocks, so block number is not enough to identify blocks from a vnode. FreeBSD use negative block numbers for extattrs, but I find it unclean, I'm not sure it won't cause problems with our buffer cache (at last block -1 is used already for vtruncbuf()), and negative blocks numbers are already used in ufs for indirect blocks. I see 2 ways to fix this: 1) Add a new bflag, B_ALTDATA. When the buffer refers to a extended attr block (and not a data block), this flag is set. This flag can also be passed to bread() and breadn() (not the same namespace, but the same B_ prefix and so the same name, this part of the buffer cache API could also be improved). When looking up a buffer in the cache we also check for this flag. For consumers to be able to specify we're looking up a B_ALTDATA buffer, incore(), getblk() and vtruncbuf() gains a new flag argument. To avoid touching a all buffer cache users, I choose to introduce incore2(), getblk2() and vtruncbuf2() with the extra argument, and the origical functions just call the *2 version with flag set to 0. This is implemented in buffer.diff, and has been tested to not introduce new problems with existing code. 2) instead of using a new flag, add a new 'int type' member to struct buf, which is opaque to the buffer cache itself (the meaning of type 0 is fs-dependant) but is checked when looking up a buffer. Type 0 would still mean regular vnode data, so that existing users won't have to be changed, other values could be used by filesystems for their internal data usage (for example, ufs could use 1 for first indirect blocks, 2, for second indirect blocks, 3 for thrird indirect blocks, and some other values for extended attributes. Another filesystem with e.g. blocks to store ACLs could also use its own type to have its ACL blocks entered in the bufcache). In addition to new incore2(), getblk2() and vtruncbuf2() functions with a type argument, we'd also need a bread2() and breadn2() with a type argument. I've not implemented this yet. have you considered to separate the entity being cached from vnode? iirc, irix called it buffer cache target or such. your vtruncbuf2 function seems to imply needs to have separate v_dirtyblkhd/v_cleanblkhd for each types. besides that, it's more natural representation for NTFS/NFSv4 style attribute forks. YAMAMOTO Takashi Althrough I've done 1 as a POC, I prefer solution 2 (the patch is mostly the same, with bflag remplaced by b_type). What do other think ? The second change needed outside of sys/ufs/ffs/ is: - new members in struct inode. This is strait from FreeBSD, and this affects modules so require a kernel version bump - ufs_inode.c:ufs_inactive() truncate extended data to 0 as well when freeing the inode. This require changes to ffs and lfs to ignore IO_EXT (for now). - ufs_vnops.c:ufs_strategy(): when requesting extended attribute data (B_ALTDATA actually), get extdata bn instead of regular bn via VOP_BMAP(). This is in ufs.diff attached. The complete diff of actual code (where extended attributes are not working yet, there's locking issues, as well as more code needed for reverse endian handling, WAPBL and fsck) is also included, so that you can see how all of this goes in together. I'd really like to be able to get this in netbsd-6 later, which would means (given my own schedule) I have to commit the kern and ufs/ufs parts before next friday if we want to avoid kernel API changes in the branch. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Mon, Jan 16, 2012 at 10:00:05PM +, YAMAMOTO Takashi wrote: have you considered to separate the entity being cached from vnode? What would this buy us ? the data are intimely tied to the inode, cleaning the cache when a file is deleted or would be more difficult, isn't it ? iirc, irix called it buffer cache target or such. your vtruncbuf2 function seems to imply needs to have separate v_dirtyblkhd/v_cleanblkhd for each types. It's possible, I didn't look at vnode cleaning yet. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
hi, On Mon, Jan 16, 2012 at 10:00:05PM +, YAMAMOTO Takashi wrote: have you considered to separate the entity being cached from vnode? What would this buy us ? the data are intimely tied to the inode, cleaning the cache when a file is deleted or would be more difficult, isn't it ? it allows us to have more than one such entities for a vnode. it's what you want here, isn't it? YAMAMOTO Takashi iirc, irix called it buffer cache target or such. your vtruncbuf2 function seems to imply needs to have separate v_dirtyblkhd/v_cleanblkhd for each types. It's possible, I didn't look at vnode cleaning yet. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Mon, Jan 16, 2012 at 10:39:45PM +0100, Manuel Bouyer wrote: Indeed. But that isn't really the question. The question is really whether we're past the date for brand-new feature proposals for netbsd-6... or at least ones that involve invasive changes. No, the question is whenever we commit the needed bits now for the feature to be pulled up without kernel API major change later, or if we accept a kernel API major change in the branch after netbsd-6-0 is branched. this won't ever be in netbsd-6 is not an option, I don't think we can wait for netbsd-7 for this. No, that's really not the question. It's been months that we've been planning out what will and won't be done in time for -6. That process finally converged and we got a firm schedule. Now you come along with something major you've never mentioned during this whole time and it just *needs* to get in at the last minute? Really, I don't think it can or should. I mean, I could cite a dozen or two other things that ought to be in netbsd-6, for various definitions of ought... many of them much less invasive and/or dangerous. They're not going to be. It's too bad, in some sense, but it's already been too long since -5 was released and some point one needs to stop and release the system one has, not the system one would want if one just had another three (or six or nine or eighteen) months. I'm sorry if I sound testy and I'm really not trying to start a fight; but we really do need to get this thing branched and shipped, and what you're proposing could easily turn into a three-month delay (if it more or less works) or six or more (if it cracks wide open). Changing the way the buffer cache is indexed is semantically intrusive even if it's not physically intrusive. While I think adding a type field to modify the block number is a good idea, for various reasons, it needs to be thought through, and it hasn't been yet and there isn't time to thrash it out fully before the branch deadline. Furthermore, there's the existing question of indexing by physical vs. virtual block numbers; that is not in any way a resolved issue and what you're proposing interacts directly with it, and this too needs to be thought through and there isn't time before the branch deadline. Yes, and I don't think we need to wait for theses questions to be sorted out to have ffs2 extended attributes. Then figure out how to do ffs2 extended attributes without changing the buffer cache. I'm sure it can be done, and without resorting to gross hacks, either. Even if the buffer cache code is rototilled later, I don't think extended attributes or the new type field will make it harder, and the code in HEAD and the netbsd-6 branch is allowed to diverge. With all due respect, you also didn't think the quota proplib stuff was going to make things harder; I've already put as much or more time into straightening it out than it took to fix ufs_rename, and it's nothing like done yet. I would like to avoid a repeat of that whole experience, partly because it's an ineffective use of scarce resources (namely, developer time, both yours and mine) and partly because such situations breed resentment and infighting. The buffer cache code desperately needs a major rework. Ideally this should be done in its entirety before anyone tries to make any new semantic extensions to it or add any new functionality, to avoid accidentally making the code worse than it already is and to avoid adding new requirements to the logic that might turn out to be impossible or vastly expensive to implement sanely. If we really need to add features or extend the behavior before the rework can get done, it's absolutely essential that all of the ramifications be sorted out in advance and chewed over by as many people as possible. I'm sure someone's going to respond to say I'm being alarmist (or at least think it) -- maybe I am, but the buffer cache, along with other similar/related code (think genfs_putpages, and also the syncer) is among the most subtle and delicate in the (or any) kernel. The implementation in NetBSD is in no way well structured or robust; the only reason it works at all is that it's been in production all this time and any regressions that appear get reverted. I also had the interesting experience of doing a new implementation of roughly the same design a couple years back; even when done carefully and tidily and stuffed full of assertions there are many subtle ways for it to go wrong... many of which I'm sure exist as unfixed problems in the NetBSD code. We *know* there's a certain background level of weird unexplainable and unrepeatable filesystem bugs. A while back I tracked one of those down, because it produced a panic with clear symptoms, and traced it to race conditions involving buffer flags. Fixing this up has been basically second on my urgent priority list after ufs_rename, which had much worse consequences. I haven't embarked on
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
Manuel Bouyer bou...@antioche.eu.org wrote: Because manu@ has put lots of efforts in getting glusterfs running, and I think it's something we can market. But it's unusable with ffsv1 extattrs, we really need something better. Well, it works, but it is so slow it suggests NetBSD is a second-class operating system. I think we need decent extended attribute support soon, this is a major feature everyone else has right now. The current situation is getting as embarassing as when we did not had PAM in 2005. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Mon, Jan 16, 2012 at 10:00:05PM +, YAMAMOTO Takashi wrote: have you considered to separate the entity being cached from vnode? iirc, irix called it buffer cache target or such. That sounds like probably a good idea, but I need to think about it more. One of the things we need to be able to do is have both physical (block numbers are device offsets) and virtual (block numbers are file offsets) buffers. Currently we do this by hanging physical buffers on the device vnode, but this has always created problems. Also for some filesystems it may be necessary or desirable to be able to take a virtual buffer and change it to a physical buffer, or to keep track of both a virtual and physical identity for the same buffer at once. I need to figure out if the latter is really necessary or not, and I don't think it'll become entirely clear until I've gotten well into hacking up LFS. your vtruncbuf2 function seems to imply needs to have separate v_dirtyblkhd/v_cleanblkhd for each types. I don't see why and I don't think makes sense, at least in the long term. The global buffer data structures hold buffers; they shouldn't care what's in them or who they belong to. Any type field becomes part of the identity of the buffer, though, and therefore part of the lookup key; that's all vtruncbuf2 is doing, although a quick look at the code suggests that it is not doing it efficiently and it may not be doing it correctly. -- David A. Holland dholl...@netbsd.org
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Mon, Jan 16, 2012 at 04:20:00PM -0500, Mouse wrote: And I think the master tree for a (supposedly-)production OS is not the place to be carrying out research experiments, not even if another such OS is already doing it. But my opinions seem to correlate negatively with NetBSD's these days. Not on that point. The trouble, of course, is that there isn't really any such thing these days as a research platform OS useful for such experiments. (I could produce one in a year or so, if anyone should happen to have deep pockets or a tame funding agency on hand. But in general the world doesn't seem to think there's any value in such an undertaking.) -- David A. Holland dholl...@netbsd.org
Re: updated patch Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Mon, Jan 16, 2012 at 10:28:57PM +0100, Manuel Bouyer wrote: I consider lfs second-class citizen at this time and if forward compat if broken for the lfs module on the branch it's probably not a big deal). I don't consider that acceptable... -- David A. Holland dholl...@netbsd.org
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Mon, Jan 16, 2012 at 08:38:28PM -0500, Mouse wrote: And I think the master tree for a (supposedly-)production OS is not the place to be carrying out research experiments, not even if another such OS is already doing it. The trouble, of course, is that there isn't really any such thing these days as a research platform OS useful for such experiments. I think NetBSD actually would be a fine platform for it. Well, sort of. For architectural experiments (as opposed to localized tweaks to filesystems or network protocols or whatever) you really want a small and flexible platform. Whether you get it by cutting down a production system or building a new system (or some mixture) the trick is figuring out what legacy stuff you need for a convincing proof of concept, and what's deadweight. NetBSD includes a lot of stuff that's deadweight for such purposes (beginning with but not limited to all the historical compat code) so as it stands it's quite a bit less than ideal. Just not in the main tree. Yes. I'd suggest just having two long-running branches, an experimental system and a production system, with things pulled back and forth as appropriate, but I think that probably needs a switch away from CVS as a prerequisite, and we all know where _that_ can of worms leads. I've got a pile of things that could go into the experimental tree myself. (They're mostly in production use on my personal machines, but that hardly qualifies as anything more than successful alpha test.) Also, maintaining NetBSD-experimental and NetBSD-production doubles certain overhead loads and increases (but not to 2x) others, thus further (putatively) draining already-scarce resources I was actually thinking about setting something like this up a while back, but there's a fairly large problem: if the experimental branch doesn't get much use it'll always be behind and always needing merging, and thus not very useful, which is a self-perpetuating state that defeats the purpose; however, if it does, there's a danger that it effectively becomes HEAD, with the production branch functioning at best like a stable branch, and that leaves us more or less where we already are except with a much worse prognosis for whether -current works on any given day. The conclusion I came to is that it isn't really a good idea. I think it might work to maintain a cut-down branch that can be used as a *base* for experiments but that does not itself actually contain any experiments (which would have to be proven on their own and then merged directly into the trunk) but it's not clear if this is worth the trouble vs. just experimenting on a private copy of HEAD. Anyway as you note it's not likely workable if it involves CVS branches. -- David A. Holland dholl...@netbsd.org
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
I'm working on porting the FreeBSD FFSv2 extended attributes support. [...] 1) Add a new bflag, B_ALTDATA. [...] 2) instead of using a new flag, add a new 'int type' member [...] Althrough I've done 1 as a POC, I prefer solution 2 ([...]). What do other think ? As a choice of approach to implementing what you want, I think 2 is better. It's far more generalizable. As a piece of SF I read once said, the number two is ridiculous and can't possibly exist. It was talking about universes, but the basic concept applies here too: there's very little excuse for any number between one and many. However, I think that constitutes a good implementation of a bad idea. This makes a file no longer a long list of octets; it becomes multiple long lists of octets. The Mac did this, with resource forks and data forks, and you may note OS X doesn't do it any longer. I suspect these will seem like a good idea for a while, until people start discovering all the things they break, or that break them, and realize that they didn't learn from history and thus had to repeat it. That said, it's no skin off my nose. I've said my piece, and it won't be affecting me, pragmatically, either way. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Sun, Jan 15, 2012 at 08:37:37PM +0100, Manuel Bouyer wrote: Althrough I've done 1 as a POC, I prefer solution 2 (the patch is mostly the same, with bflag remplaced by b_type). What do other think ? (2) is conceptually what NTFS does IIUC. Consider a file to be a database table to which arbitrary columns may be added, with column 0 containing all the traditional octets, and some columns having special meaning. I am not sure I like the idea, but it clearly is superior to option (1). Martin
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
Mouse mo...@rodents-montreal.org wrote: The Mac did this, with resource forks and data forks, and you may note OS X doesn't do it any longer. I suspect these will seem like a good idea for a while, until people start discovering all the things they break, or that break them, and realize that they didn't learn from history and thus had to repeat it. The problem with multiple-forked files is interaction with the outter world. When you upload a file on the internet, you loose the non data-forks, except if you serialize in some way (the .hqx format did that just for the mac). How things will work on a NFS filesystem is also an issue: you may not want mv(1) or cp(1) to strip non-data fork Anyway we already have the problem with ffsv1 extended attributes. I added extattr support to cp(1) and mv(1), but there is a lot of work left to do: dump, restore, tar, cpio, zip, unzip, scp, rcp, rsync... Of course there will be situation where protocols or format will not allow preservation of extended attributes. In that case, the program may need to warn the user about lost data. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
