> >> Cyrus puts one folder on one partition. you can put subfolders on >> other partitions, but you cant have two partitions connected with one >> folder. >> Cyrus has no way to decide where it would store the email on disk and >> it would cost more time to merge these partitions in memory if a usere >> access his mailfolder. This structure is used in all parts of cyrus. >> To implement >> something like this would be fundamental work like writing a new >> mailserver. >> > Hm, does cyrus ever scan the content of filesystem (files,subfolders)? > Or it uses direct access to filesytem objects like files and folders > based on information from inner database? > > What is about creating subpartitions like: > > /partition1/sub1/u/user/user1/*messages* > /partition1/sub2/u/user/user1/*messages* > /partition1/sub3/u/user/user1/*messages ? > > Creation of subpartitions seems to be fundamental too? > >> >>> I would like to make extendable (by size) user mailboxes, but I don't >>> want to move accounts over partitions when disk space becomes low, >>> instead I want to attach new storages and store new mail there. >>> >> >> There are more easy ways to do what you want. >> 1. you can move user or subfolder to an other partition. >> In murdersetup you can do this even accros mailserver, without >> downtime, >> if you run short in memory, cputime or bandwidth. > Moving of accounts will cause downtime of the current account and will > cause high loads on hardware when accounts are large... > Also I want to be able to extend size of user's accounts without pain > when my boss will ask to extend them x10 or x100 ..... > >> >> 2. you can put the partition on a filesystem/lvm-volume which supports >> resizing, so you can add a new dist to the volume and resize it. >> > May somebody recommend reliable/safe filesystem that support resizing? > I'm afraid to use anything except ext3 in production enviroment... We are using XFS on LVM for years now with cyrus-imapd and it has always worked very well. Online expansion with this combination has saved us from many hours of downtime over the years. Simon ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html