Όλα τα χρόνια που κάνω αυτή τη δουλειά ποτέ δεν ήμουν οπαδός των quotas. Το όριο χρήσης ενός πόρου, όσο κι αν προκύπτει από μετρήσεις ή εκτιμήσεις δεν παύει στην πραγματικότητα να είναι αυθαίρετο. Κι ας υπάρχει αντικειμενικός λόγος που το θέτει εν ισχύ κάποιος: Η συνολική προστασία του συστήματος και η εξασφάλιση της συνέχισης της λειτουργίας του. Το όριο είναι αυθαίρετο γιατί υπάρχει πάντα εκείνος ο χρήσης που είναι λίγο πάνω από αυτό και με καλό λόγο.
Αν υποθέσουμε πως κάποιος έχει όριο στο home directory του τα 200MB, όταν αυτά ξεπεραστούν για 10 bytes (ή και λιγότερα ακόμα), πως μπορεί να ξέρει το σύστημα εάν αυτό συμβαίνει επειδή αποθηκεύει ο χρήστης ένα paper σημαντικό για την εργασία του ή ένα MP3; Απάντηση: Το σύστημα δεν μπορεί να ξέρει. Άσε που για το χρήστη το MP3 μπορεί να είναι και ισοδύναμα σημαντικό. Το σύστημα ξέρει μόνο νούμερα. Έχεις μέχρι N-bytes. Στα N+1… tough luck.
Για αυτό ποτέ στις δουλειές μου μέχρι τώρα δεν υλοποίησα ένα τέτοιο σύστημα. Όσο ισχυρά κι αν διατυπώθηκε η απαίτηση. Κι ας είναι οι χρήστες σαν ιδανικά αέρια. Γιατί αυτά τα 10 bytes παραπάνω μπορεί να είναι σημαντικά. Και γιατί για αυτά τα 10bytes (ενώ υπάρχει χώρος) ο χρήστης μπορεί να κάνει κατεργαριές που να προκαλέσουν βλάβη στο σύστημα. Ενώ αυτός το μόνο που θέλει, είναι να κάνει τη δουλειά του. Το έχω δει. Αντίθετα, στα “δικά μου συστήματα” εάν κάποιος έπαιρνε είδηση πως παρόλο που υπάρχουν δεδηλωμένα quota limits, αυτά ήταν μόνο “στα χαρτιά” και εκμεταλλευόταν το γεγονός, μια παράκληση του τύπου “Κάντε ένα clean-up γιατί διαφορετικά θα πρέπει να τα υλοποιήσω για όλους” αρκούσε.
Οι καιροί όμως αλλάζουν. Και μπορεί οι ISPs να μη δίνουν (όλοι) IMAP, αλλά δίνουν webmail access. Το Gmail αλλάζει τον τρόπο με τον οποίο αντιμετωπίζουν οι χρήστες την αλληλογραφία τους, ανεξάρτητα από τον mail provider. Και όλο και πιο πολλοί χρήστες “γλυκαίνονται” και επιλέγουν το “leave messages on server” στον POP3 client τους. Έτσι και το (μαθηματικό) μοντέλο αλλάζει. Ο mail (POP3) server δεν είναι πλέον ο ενδιάμεσος σταθμός. Είναι ο τελικός. Και αυτό τα αλλάζει όλα. Αυτά το +10 bytes γίνονται ξαφνικά πολύ σημαντικά, γιατί η υπέρβασή του ορίου δεν είναι στιγμιαία ή παροδική. Είναι μόνιμη.
Έτσι την προηγούμενη εβδομάδα για πρώτη φορά (ελπίζω και τελευταία) και με βαριά καρδιά, έκανα strong enforcement. Ελπίζω προσωρινά.
Τώρα αν μπορούσα να απαλλαγώ και από τα υπόλοιπα καθήκοντά μου ώστε να γράψω drivers για να παίζει το IMAP toolkit πάνω από κάτι σαν το HDFS…
Managing organized complexity 
Χρόνια Πολλά! Διάβαζα το πρωί για τον Reiser, και για κάποιο λόγο το θυμήθηκα βλέποντας τα quota σου…
http://www.theregister.co.uk/2008/04/29/hans_reiser_found_guilty/
@Stazybο Hοrn:
Ευχαριστώ για τις ευχές. Εννοώ απαλλαγή από τα “εργασιακά” μου καθήκοντα. Τα οικογενειακά καθήκοντα βοηθάνε την εργασιακή ζωή. Δεν ξέρεις ποτέ πόσο ελεύθερο χρόνο είχες διαθέσιμο πριν κάνεις οικογένεια. Και αυτή η διαπίστωση και μόνο, σε κάνει optimizer.
Ο nerderer από την άλλη έδειξε πως δεν μπορεί να χειριστεί καταστάσεις έξω από το software που γράφει, και κυρίως προσωπικές ήττες.
Στην σχολή μας (cs.uoi.gr) πριν κάποια χρόνια υπήρχε quota για το home directory 10Mb (όταν μπήκα, το 2001). Στην πορεία το κάνανε 50Mb. Πλέον το κάνανε 100Mb.
Το quota στα home directory ποτέ δεν ήταν πρόβλημα. Η μεγαλύτερη μλκία έβερ ήταν το quota στο mail: 15Mbyte. Το οποίο τι σήμαινε?! Αν σου έστελνε κάποιος 2 attachment, χωρίς καμία προειδοποίηση (και τι να σου στείλουνε?) κανείς άλλος δε μπορούσε να σου στείλει email. Έτσι απλά. Πόσα emails έχασα με αυτό τον τρόπο… (μέχρι που έβαλα gmail και πλέον τα τραβάω από το cs και τα διαγράφω. Ουσιαστικά μόνο σαν “forward” μπορεί να λειτουργήσει ένα email με 15Μb quota, τι να αφήσεις εκεί?)
Οντως, αλλάξαν οι καιροί..
Οπως έχει πει και ο Tom Limoncelli..
(ref)
Καλημέρα,
άσχετο με την δημοσίευση: Πολλές ευχές για την ονομαστική εορτή.
ξέχασα να βάλω smilies…
@Stazybο Hοrn:
No worries
@Ντροπαλός:
Ευχαριστώ!
@stsimb:
T.L. rules.
Χρόνια πολλά Γιώργο (έστω και καθυστερημένα).
Με το e-mail δεν είμαι σίγουρος εάν το πραγματικό πρόβλημα είναι το γεγονός του χώρου. Με τα soft quota κάπου στο 80% και αρκετά ενοχλητικά mail κάπου μπορούν να περιοριστούν οι χρήστες. Το ιδανικό βέβαια είναι να αυτοπεριορίζονται και να μην χρειάζεται να κάνεις τον αστυνόμο.
Θεωρώ ότι το cpu/memory overhead της διαχείρισης ενός λογαριασμού με χιλιάδες (ή δεκάδες χιλιάδες π.χ. στο gmail μου) mail, πολλαπλασιασμένο με μερικές εκατοντάδες χρήστες online στο webmail, είναι ο πραγματικός εχθρός του συστήματος.
Σχετικά με τα ενοχλητικά mail: Εξαρτάται απο το ‘education’ που έχουν οι χρήστες.. Πόσο πολύ τους ενδιαφέρει το email, πόση σημασία του δίνουν και αν έχουν άλλους εναλλακτικούς τρόπους επικοινωνίας..
Ενω μέχρι πριν δύο χρόνια μπορώ να πω ότι το σύστημα των warnings έκανε τη δουλειά του, οι χρήστες άδειαζαν το mailbox τους όταν έπαιρναν τέτοια mails, δυστυχώς σήμερα δεν ισχύει το ίδιο. Η λίστα με αυτούς που ξεπερνάνε το warning threshhold (και λίγο μετά το quota) έχει τους ίδιους εδώ και καιρό και καθημερινά προστίθονται κι άλλοι..
Ο χώρος επίσης δεν είναι αμελητέο (και φτηνό) πρόβλημα, γιατί συνήθως χρειάζονται SAN με RAID5 arrays και commercial filesystems..
Το I/O είναι ο πραγματικός εχθρός του συστήματος..
@Vaggelis:
Θα συμφωνήσω με το Σωτήρη. Το email είναι network bound (βγάλε έξω το antispam / antivirus filtering γιατί γίνεται πριν το delivery και σε άλλα υποσυστήματα). Ένα webmail interface είναι ακόμα ένας client. Η ιδιαιτερότητα που έχει είναι πως για κάθε χρήστη τρέχει σε δύο και όχι σε ένα σύστημα. Σημασία έχει όμως πως δεν τρέχει πάνω στο storage. Άρα για το storage είναι ακόμα ένας client και τίποτε άλλο (ειδικά εάν έχεις λάβει τα μέτρα σου και τρέχεις κάποιο σωστό IMAP proxy).
Στην απλή περίπτωση, ένας mail server είναι ένα σύστημα M/M/1 με σταθερό λ και μ. Στην περίπτωση ενός ISP που έχει καταφέρει να έχει σύστημα χωρίς ιδιαίτερο φόρτο, μπορείς πάλι να δεις το σύστημα εισερχόμενης αλληλογραφίας σαν M/M/N. Με την ιδιομορφία πως το μ αλλάζει όσο αυξάνει το μήκος της ουράς (για να προσομοιώσεις τις καθυστερήσεις από το filesystem).
Πρόσεξε τώρα όμως τι συμβαίνει: Εάν το λ γίνεται πολύ μεγάλο και ξεπερνάει το μ, τότε το πρόβλημα λύνεται φτηνά αγοράζοντας γρηγορότερα ή/και περισσότερα CPU. Δεν είναι το ίδιο φτηνή η λύση όταν ο buffer πάψει να είναι άπειρος και σου μεταβάλλει το σύστημα από M/M/N σε M/M/N/K.
Αυτό κάνει όμως το webmail όταν αρχίζει και καθιερώνεται ως ο βασικός mail client: Αλλάζει τη μοντελοποίηση του storage. Η τελική αποθήκευση του email παύει να είναι ανάγκη για την οποία απασχολείται ο χρήστης. Και από εκεί που με άνεση μπορούσες να θεωρείς για τους χρήστες σου πως υπάρχει άπειρο buffer, αυτό πια δεν είναι ασφαλής υπόθεση. Ο εύκολος τρόπος είναι να μοιράζεις το userbase σε μηχανήματα, αλλά δεν είναι ο optimal. Οι χρήστες αλλάζουν συμπεριφορά, πρέπει να βρίσκεις τους system-friendly και να βρεις κάθε πόσους τέτοιους μπορείς να βάζεις μαζί ένα που αφήνει τα email στον server, ποιος αλλάζει συμπεριφορά και πότε (εάν γίνεται να το προβλέψεις). Ακόμα κι αν φτιάξω μοντέλλο για κάτι τέτοιο, αμφιβάλλω εάν θα μου αγοράσουν το CPLEX για να το λύσει.
Για αυτό και με ενδιαφέρει κάτι σαν το HDFS ή το Hypertable. Γιατί για τις ίδιες απαιτήσεις hardware (πάνω-κάτω) δεν χρειάζεται να ψάχνω για το CPLEX ή αντίστοιχο problem solver.
@adamo,sotiris: Εξαιρετικές και διαφωτιστικές οι απαντήσεις από ανθρώπους που έχουν κάποιες δεκάδες (εκάτοντάδες) χιλιάδες χρήστες.
Η απορία μου είναι σχετικά με το I/O που προκαλεί το Next Page click, από το page 42 στο page 43, click στο webmail ενός χρήστη με 3000 mail. Μπορεί ενας καλά ρυθμισμένος IMAP proxy να λύσει το πρόβλημα;
Έχει νόημα η χρήση κάποιας μεγάλης βάσης δεδομένων για την αποθήκευση των e-mail και να γίνει reduce το filesystem πρόβλημα, σε database optimization πρόβλημα;
Τέλος, υπάρχουν ειδικά filesystems optimized για e-mail storage;
@Vaggelis:
Εάν ο webmail client ή ο IMAP proxy ακολουθεί τις 10 εντολές όλα είναι καλά. Τέτοιος είναι ο imapproxy.
Το DBmail project είναι μια προσπάθεια προς την κατεύθυνση να σώζονται τα emails σε μια database. Έχω πειστεί πως δεν είναι αποδοτικό να αποθηκεύεται το email ενός χρήστη σε ένα RDBMS ή ένα σύστημα Object-Relational. In the long run θα είναι δύσχρηστο. Δες και το “To BLOB or Not To BLOB: Large Object Storage in a Database or a Filesystem?” του Jim Gray.
Όσο για το αν υπάρχουν ειδικά filesystems, δεν μπορώ να σου απαντήσω “ορθά”. Μπορώ να σου πω πως εγώ αποφεύγω το ext3 για “πολλά” αρχεία σε ένα directory. Αντίθετα υπάρχουν πολλά mailbox formats, με πιο πετυχημένα (IMHO) το traditional unix mailbox format, το mbx, και το maildir (OK και το Cyrus). Μπορείς να χρησιμοποιήσεις και άλλες τεχνικές, όπως π.χ. απευθείας delivery στο $ΗΟΜΕ, ή το spool να έχει ιεραρχική δομή αντί για flat που είναι το σύνηθες κ.λπ.
@adamo
Ευχαριστώ για την απάντηση. Στο paper που είδα, συσχετίζεται το NTFS με τον SQL Server της Microsoft.
Ο συσχετισμός επί του προκειμένου μου φαίνεται λίγο άνισος γιατί ο SQL Server δουλεύει πάνω στο NTFS.
Θα είχε πολύ ενδιαφέρον να βλέπαμε κάποιο filesystem vs ενός RDBMS με δικό του raw partition.
Όπως ορθά αναφέρει (επιπρόσθετα) δεν αποθηκεύουν τα BLOB όλα τα RDBMS πάνω στο physical db storage (π.χ. η DB2 έχει associative array με filenames των αρχείων στο δίκο).
Έχω μεγάλη απορία τι κάνει πάνω σε αυτό το θέμα το Google όπου έχουμε δει το αντίστροφο (GmailFS xexexe)
@Vaggelis:
Δεν έχει πολύ σημασία πια το raw partition vs αρχεία στο δίσκο. Τις παλιές εποχές που ο controller του δίσκου ήταν πιο χαζός, δεν είχε τόσο μεγάλη cache και δεν αποφάσιζε μόνος του που θα στείλει τα data είχε περισσότερο νόημα. Στο raw partition το DBMS υλοποιούσε πρακτικά το δικό του filesystem. Ότι κάνει δηλαδή και σήμερα πάνω σε ένα αρχείο (δες το σαν εικονικό filesystem on a file).
To Gmail αποθηκεύει πάνω από το BigTable και φαντάζομαι το Yahoo! Mail πάνω από το Hadoop (και εάν δεν τον κάνει ήδη, θα το κάνει στο μέλλον).
@adamo:
“Το DBmail project είναι μια προσπάθεια προς την κατεύθυνση να σώζονται τα emails σε μια database. Έχω πειστεί πως δεν είναι αποδοτικό να αποθηκεύεται το email ενός χρήστη σε ένα RDBMS ή ένα σύστημα Object-Relational.”
Aπό http://www.funtoo.org/en/articles/linux/ffg/1/:
“Now, conventional wisdom would say that you aren’t supposed to store that many ridiculously small files on a filesystem. Instead, they should be stored in some kind of database that runs above the filesystem. In reply, Hans Reiser would point out that whenever you need to build a layer on top of the filesystem, it means that the filesystem isn’t meeting your needs. If the filesystem met your needs, then you could avoid using a special-purpose solution in the first place. You would thus save development time and eliminate the code bloat that you would have created by hand-rolling your own proprietary storage or caching mechanism, interfacing with a database library, etc.”
Γενικώς όπου υπάρχουν πολλά μικρά αρχεία, η καλύτερη επιλογή filesystem είναι το ReiserFS.
Το ReiserFS έχει τη δυνατότητα να κάνει allocation του ακριβούς μεγέθους του αρχείου, σε αντίθεση με το ext3 που κάνει allocation σε fixed blocks (προσδιορίζεται κατά τη δημιουργία).
Aν έχεις Maildir format (ή Maildir-like όπως το Cyrus IMAPd), δηλαδή πολλά μικρά αρχεία, το ReiserFS είναι μάλλον η καλύτερη επιλογή.
Αν έχεις mbox format (ένα μεγάλο αρχείο), τότε μάλλον ext3.
Aν θες Maildir format με ext3, καλό είναι να επιλέξεις small blocks και low bytes-per-inode ratio (δηλαδή high inode-to-file ratio).
BOFH: You say you need more filespace?
Seems to me you have plenty left…”