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
> > appli
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
matthew green wrote:
>
> > 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).
> > >
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 uf
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 * i
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 wi
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
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 th
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 bu
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
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.
>
> irregardl
> 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
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...
>
I am in
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 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
On Tue, Jan 17, 2012 at 06:10:21PM +, David Holland wrote:
> On Tue, Jan 17, 2012 at 10:14:57AM +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 dea
On Tue, Jan 17, 2012 at 10:14:57AM +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 o
On Tue, Jan 17, 2012 at 12:55:03AM +, David Holland wrote:
> 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 l
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'
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, cleani
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 reall
>> 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 suc
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
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 t
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
Manuel Bouyer 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
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 whe
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 ?
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 c
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 do
On Mon, Jan 16, 2012 at 10:45:03PM +0100, Martin Husemann wrote:
> 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?
Because manu@ has put lots of eff
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
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
>> 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
On Sun, 15 Jan 2012 15:21:40 -0500 (EST)
Mouse 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
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 o
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
> > change
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 a
Mouse 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 fr
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 arbi
> 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 appro
41 matches
Mail list logo
